Pagina, layout, slot e blocco: cosa offre ogni confine

Il modello di contenuto principale WebBlocks CMS si inserisce in una riga:

Page -> Layout -> Slots -> Blocks

Può sembrare una gerarchia utile o una cerimonia non necessaria. Perché non memorizzare una pagina come un albero componente e renderla? Questo approccio è valido per molti prodotti. Quattro strati espliciti guadagnano il loro posto solo quando ciascuno possiede un diverso tipo di cambiamento.

Una pagina risponde a domande sul documento come oggetto pubblicabile: quale sito ne è proprietario, qual è il suo percorso pubblico in ciascuna locale, se è bozza, in revisione o pubblicato, quale layout utilizza e quali metadati, risorse e cronologia delle revisioni gli appartengono.

Tali preoccupazioni sopravvivono quando il contenuto visibile cambia. La sostituzione di un eroe, lo spostamento di un paragrafo o l'aggiunta di una galleria non dovrebbero creare una nuova identità di routing.

Anche il contrario è utile. Lo spostamento o la duplicazione di una pagina può essere trattata come un'operazione di pagina controllata. Il sistema sa quali traduzioni, slot, alberi di blocchi di proprietà della pagina, risorse e relazioni di revisione viaggiano con esso. Una pagina è più del nodo radice di un array di componenti.

Un layout definisce quali aree può avere una pagina e in che modo tali aree appartengono alla shell pubblica. Un layout predefinito potrebbe fornire un'intestazione, un'area principale e un piè di pagina; un layout di documentazione può aggiungere una barra laterale.

Il layout può definire l'ordinamento, gli elementi wrapper semantici, le classi wrapper e una classe dell'ente pubblico. Possiede la struttura esterna in cui viene visualizzato il contenuto, quindi i blocchi non devono risolvere la domanda: Che tipo di shell di pagina sono all'interno?

Una barra laterale della documentazione non dovrebbe esistere poiché un blocco di contenuto ha emesso un wrapper della barra laterale. Il layout dei documenti possiede quella regione. I blocchi posizionati al suo interno rimangono contenuto anziché diventare segretamente l'architettura della pagina.

Esiste un costo: la modifica di un layout è strutturale, non meramente visiva. WebBlocks pertanto non elimina o riscrive automaticamente gli spazi di pagina esistenti quando cambia la selezione di un layout. Gli slot mancanti possono essere aggiunti esplicitamente, mentre gli slot extra vengono segnalati e conservati.

Uno slot collega la promessa strutturale del layout a una pagina particolare. Nomi come header, main, sidebar e footer portano un significato oltre la posizione. Il renderer pubblico può scegliere un wrapper semantico per la regione e gli strumenti possono indirizzarlo senza indovinare dove si trova in un albero JSON.

Uno slot di pagina WebBlocks ha un'origine esplicita: page esegue il rendering dei blocchi di proprietà di questa pagina, shared_slot esegue il rendering di un albero di blocchi riutilizzabile con ambito sito compatibile e disabled preserva la regione senza eseguire il rendering di blocchi al suo interno.

Il riutilizzo è quindi un riferimento anziché una copia. Un'intestazione condivisa può essere aggiornata una volta e resa da ogni pagina che fa riferimento ad essa. L'impatto più ampio rimane visibile: Shared Slots ha le proprie revisioni e il proprio flusso di lavoro di pubblicazione.

La pagina che la utilizza possiede ancora il wrapper dello slot. Un Shared Slot contribuisce solo all'albero dei blocchi interno, impedendo al contenuto riutilizzabile di portare una seconda shell di pagina nella pagina che lo utilizza.

I blocchi sono le unità editoriali inserite in uno slot. Un blocco può rappresentare un'intestazione, un rich text, un'immagine, una navigazione, una galleria o un layout primitivo come una pila o una griglia. I blocchi supportati possono contenere blocchi secondari, quindi il contenuto all'interno di uno slot può comunque formare un albero.

Il vincolo importante è quali blocchi non possiedono. Un blocco non dovrebbe decidere il percorso della pagina, lo stato del flusso di lavoro o la shell esterna. Possiede i suoi contenuti, traduzioni, impostazioni, relazioni e rendering all'interno della regione che gli è stata assegnata.

Ciò migliora la convalida. Una testata ha un contratto diverso da una galleria. Uno strumento di automazione può scoprire schemi digitati anziché modificare un documento di pagina senza restrizioni. Il rendering e la migrazione possono controllare le relazioni invece di eseguire il reverse engineering di un BLOB.

L'archiviazione relazionale non è automaticamente superiore a JSON. Rende più chiare alcune regole di integrità e migrazioni introducendo più tabelle e join. WebBlocks accetta tale costo perché la proprietà esplicita è importante per i suoi flussi di lavoro multisito, localizzazione, revisione e automazione.

Considerare una pagina di installazione in un sito di documentazione:

Ogni modifica ora ha un proprietario naturale. La modifica di /docs/installation appartiene al flusso di lavoro di traduzione e routing delle pagine. L'aggiunta di un binario strutturale fa parte del layout. La navigazione della documentazione in sostituzione appartiene allo slot della barra laterale o al suo Shared Slot. La modifica di un comando di installazione appartiene al blocco Code.

La gerarchia è utile perché indica sia alle persone che agli strumenti a cosa appartiene una modifica.

L'architettura chiara non garantisce un editor chiaro. Se qualcuno deve navigare manualmente Pagina -> Layout -> Slot -> Blocca ogni volta che vuole correggere una frase, il modello si infiltra nel flusso di lavoro. La ricerca, i riepiloghi utili, i collegamenti di modifica diretta e le impostazioni predefinite ragionevoli dovrebbero consentire alle attività di routine di saltare i livelli senza cancellarli dal sistema.

Il modello può anche diventare sovraprogettato. Un sito con un modello fisso e una manciata di campi potrebbe non trarre vantaggio da layout configurabili o alberi di slot riutilizzabili. Un modello di pagina digitata o un semplice documento Markdown potrebbe essere lo strumento migliore.

Quattro domande aiutano a verificare se un livello sta guadagnando il suo posto:

1. Possiede un tipo distinto di cambiamento?
2. È possibile convalidare tale modifica in modo indipendente?
3. Il confine impedisce un reale stato non valido?
4. La modifica di routine può evitare di sostenere l'intero costo della complessità?

Se la risposta alle prime tre è no, lo strato potrebbe essere cerimoniale. Se la risposta alla quarta è no, l'architettura potrebbe essere solida mentre l'esperienza del prodotto necessita ancora di lavoro.

Page -> Layout -> Slot -> Block non è presentato come una nuova invenzione. Regioni, componenti e contenuti strutturati esistono già da molto tempo nei prodotti CMS.

Il punto è la proprietà esplicita. Le pagine possiedono identità e flusso di lavoro. I layout possiedono la shell. Gli slot possiedono un posizionamento con nome e una fonte di contenuto. Blocca il proprio contenuto.

Questi confini guadagnano il loro posto quando un cambiamento può avvenire all'interno di uno di essi senza costringere gli altri a fingere di essere cambiati anche loro.

Dove si traccia il confine tra struttura della pagina e contenuto in un CMS basato su blocchi e quale confine causa maggiori attriti per gli editor?