Il ruolo dello sviluppatore

In GajaCms struttura e contenuto sono responsabilita distinte, e la separazione e vincolante. Lo sviluppatore configura che cosa esiste e come si presenta; l'operatore sceglie e scrive che cosa dire, senza poter intervenire sul layout.

Il criterio con cui una proprieta finisce da una parte o dall'altra e diretto: se puo alterare l'aspetto del sito appartiene allo sviluppatore, se cambia il significato di cio che il sito comunica appartiene all'operatore. Padding, colori, breakpoint e animazioni non entrano nel pannello: vivono nel codice del frontend.

Ne discende la conseguenza pratica piu visibile nel pannello: l'operatore non incontra mai i nomi tecnici dei componenti, con l'unica eccezione del paragrafo. Vede il nome del preset che lo sviluppatore ha preparato, non la struttura che c'e sotto.

L'attivita si divide fra il pannello, dove si configura il perimetro entro cui l'operatore lavora, e il progetto frontend, dove si costruisce il sito che consuma l'API.

Il preset e lo strumento centrale del ruolo. Un componente di GajaCms e generico: il preset lo specializza, gli assegna un nome comprensibile e ne stabilisce la disponibilita.

Un preset vive su due piani. Nel pannello dichiara il proprio perimetro: in quali aree e su quali tipi di pagina compare, quali slot del componente sono attivi, quale layout usano gli elementi ripetuti. Nel frontend e il codice a stabilire come si presenta: il payload trasporta il codice del preset nella proprieta presetCode, e il progetto frontend riconosce quel codice e rende il blocco di conseguenza.

Non esiste quindi un costruttore visuale di preset nel pannello: la resa e codice, e resta dove il codice si scrive. Il pannello governa la disponibilita, non l'aspetto.

• I preset sono contestuali: uno disponibile nell'area di un articolo puo non esserlo nella descrizione di un prodotto. Il controllo e granulare.

• Un preset puo essere marcato per l'inserimento automatico: viene aggiunto a ogni nuova pagina creata in quell'area. Serve per i blocchi strutturali obbligatori, come una nota legale o un blocco di contatto in chiusura.

• Il nome del preset e cio che l'operatore legge. Conviene sceglierlo nel linguaggio del sito, non in quello del codice: Presentazione, Hero principale, Testimonianze, FAQ.

Il layout e il modello di pagina: stabilisce quali zone esistono e quante aree di contenuto sono disponibili. E il livello sopra i preset, e ne condiziona la disponibilita, perche i preset sono dichiarati per area.

La stessa struttura si ritrova nel payload dell'API. La risposta di una pagina espone le regioni comuni al sito, header e footer fra le altre, e le aree di contenuto della singola pagina, ciascuna con il proprio tipo e il proprio indice. Progettare i layout nel pannello significa quindi decidere la forma del payload che il frontend ricevera.

Allo stesso livello si collocano la navigazione condivisa, i menu e i componenti che compaiono su tutte le pagine: sono configurati una volta per sito e per lingua, e arrivano identici in ogni risposta.

Le immagini non vengono pubblicate come caricate. Lo sviluppatore definisce i preset di elaborazione: per ogni impiego stabilisce le risoluzioni da generare, cosi che l'operatore possa caricare un file qualsiasi e ottenere le varianti corrette.

Il caso tipico e la copertina della home page, per cui si stabilisce che l'immagine venga elaborata a una risoluzione per desktop e a una per schermi ridotti. La configurazione si applica poi a ogni sito che usa quel preset.

L'esito si legge nel payload: ogni contenuto multimediale espone la variante principale, quella per schermi ridotti quando prevista, la miniatura e le dimensioni native. Il frontend le usa senza doverle calcolare, e le dimensioni servono a evitare lo spostamento del layout durante il caricamento.

Il pannello raccoglie anche cio che il sito deve caricare oltre al proprio contenuto. Sono configurazioni tecniche, invisibili all'operatore, che il frontend riceve nella risposta di ogni pagina e applica al documento.

• I servizi di terze parti, con le rispettive chiavi: analitiche, contenitori di tag, mappe, piattaforme di gestione del consenso.

• Le risorse lato client dichiarate dallo sviluppatore: meta tag, script esterni e inline, fogli di stile, frammenti di markup, ciascuno con la propria posizione nel documento e, dove serve, la categoria di consenso che ne subordina il caricamento.

• I template delle email inviate dal sito, che restano di competenza tecnica e non redazionale.

GajaCms e headless: il sito pubblico e un progetto indipendente, scritto con lo stack che lo sviluppatore preferisce, che ottiene i contenuti dall'API pubblica. Il pannello non impone ne genera markup.

Il flusso di una pagina e sempre lo stesso. Il frontend riceve l'URL richiesto dal visitatore, lo inoltra all'endpoint di risoluzione e ottiene un unico oggetto con la route, i metadati, le regioni comuni e le aree di contenuto. Da li costruisce il documento: percorre i componenti nell'ordine ricevuto e, per ciascuno, sceglie la propria resa in base al tipo e al codice del preset.

Il lavoro di rendering consiste quindi nel tenere allineate due cose: i preset dichiarati nel pannello e i blocchi che il progetto sa disegnare. Il resto del contratto e stabile e non cambia da pagina a pagina.

La sezione API descrive il contratto nel dettaglio. La Panoramica introduce base URL, requisiti comuni e organizzazione degli endpoint; Interrogazione delle pagine descrive la chiamata principale, quella da cui parte ogni rendering.

Prima di scrivere il primo componente conviene avere chiaro il contratto della risposta di pagina: e la struttura su cui poggia tutto il progetto frontend, e conoscerla in anticipo evita di riscrivere la resa dei blocchi a meta lavoro.