The role of the developer

In GajaCms structure and content are distinct responsibilities, and the separation is binding. The developer configures what exists and how it looks; the operator chooses and writes what to say, without being able to intervene on the layout.

The criterion by which a property ends up on one side or the other is direct: if it can alter the appearance of the site it belongs to the developer, if it changes the meaning of what the site communicates it belongs to the operator. Padding, colors, breakpoints, and animations do not enter the panel: they live in the frontend code.

The most visible practical consequence in the panel is that the operator never encounters the technical names of the components, with the only exception of the paragraph. They see the name of the preset the developer prepared, not the structure underneath.

The activity is divided between the panel, where the perimeter within which the operator works is configured, and the frontend project, where the site that consumes the API is built.

The preset is the central tool of the role. A GajaCms component is generic: the preset specializes it, assigns it a comprehensible name, and establishes its availability.

A preset lives on two levels. In the panel it declares its perimeter: in which areas and on which page types it appears, which component slots are active, which layout repeated elements use. In the frontend it is the code that determines how it looks: the payload carries the preset code in the presetCode property, and the frontend project recognizes that code and renders the block accordingly.

Therefore, there is no visual preset builder in the panel: the rendering is code, and it remains where the code is written. The panel governs availability, not appearance.

• Presets are contextual: one available in the area of an article may not be in the description of a product. The control is granular.

• A preset can be marked for automatic insertion: it is added to every new page created in that area. It is used for mandatory structural blocks, like a legal notice or a contact block at the end.

• The preset name is what the operator reads. It is advisable to choose it in the site's language, not in code language: Presentation, Main Hero, Testimonials, FAQ.

The layout is the page model: it determines which zones exist and how many content areas are available. It is the level above presets and conditions their availability, because presets are declared per area.

The same structure is found in the API payload. The response of a page exposes the regions common to the site, header and footer among others, and the content areas of the single page, each with its own type and index. Designing layouts in the panel therefore means deciding the shape of the payload the frontend will receive.

At the same level are shared navigation, menus, and components that appear on all pages: they are configured once per site and per language, and arrive identical in every response.

Images are not published as uploaded. The developer defines processing presets: for each use, they establish the resolutions to generate, so the operator can upload any file and get the correct variants.

The typical case is the homepage cover, for which it is established that the image is processed at one resolution for desktop and one for smaller screens. The configuration then applies to every site using that preset.

The result is read in the payload: every multimedia content exposes the main variant, the one for smaller screens when provided, the thumbnail, and the native dimensions. The frontend uses them without having to calculate them, and the dimensions help avoid layout shifts during loading.

The panel also collects what the site must load beyond its own content. These are technical configurations, invisible to the operator, which the frontend receives in the response of every page and applies to the document.

• Third-party services, with their respective keys: analytics, tag containers, maps, consent management platforms.

• Client-side resources declared by the developer: meta tags, external and inline scripts, style sheets, markup fragments, each with its own position in the document and, where needed, the consent category that conditions their loading.

• Email templates sent by the site, which remain technical and not editorial responsibility.

GajaCms is headless: the public site is an independent project, written with the stack the developer prefers, which obtains content from the public API. The panel neither imposes nor generates markup.

The flow of a page is always the same. The frontend receives the URL requested by the visitor, forwards it to the resolution endpoint, and obtains a single object with the route, metadata, common regions, and content areas. From there it builds the document: it goes through the components in the received order and, for each, chooses its rendering based on the type and preset code.

The rendering work therefore consists in keeping two things aligned: the presets declared in the panel and the blocks the project knows how to render. The rest of the contract is stable and does not change from page to page.

The API section describes the contract in detail. The Overview introduces base URL, common requirements, and endpoint organization; Page querying describes the main call, the one from which every rendering starts.

Before writing the first component, it is advisable to have a clear understanding of the page response contract: it is the structure on which the entire frontend project rests, and knowing it in advance avoids rewriting block rendering halfway through the work.