Seite, Layout, Slot und Block: Der Nutzen klarer Grenzen

Das Kerninhaltsmodell WebBlocks CMS passt in eine Zeile:

Page -> Layout -> Slots -> Blocks

Dies kann wie eine nützliche Hierarchie oder eine unnötige Zeremonie aussehen. Warum nicht eine Seite als einen Komponentenbaum speichern und rendern? Dieser Ansatz gilt für viele Produkte. Vier explizite Ebenen verdienen ihren Platz nur, wenn jede eine andere Art von Änderung besitzt.

Eine Seite beantwortet Fragen zum Dokument als veröffentlichungsfähigem Objekt: Welcher Site gehört es, wie lautet seine öffentliche Route in jedem Gebietsschema, ob es sich um einen Entwurf, eine Prüfung oder eine Veröffentlichung handelt, welches Layout es verwendet und welche Metadaten, Assets und Revisionshistorie dazu gehören.

Diese Bedenken bleiben bestehen, wenn sich sichtbare Inhalte ändern. Durch das Ersetzen eines Helden, das Verschieben eines Absatzes oder das Hinzufügen einer Galerie sollte keine neue Routing-Identität entstehen.

Auch die Umkehrung ist nützlich. Das Verschieben oder Duplizieren einer Seite kann als kontrollierter Seitenvorgang behandelt werden. Das System weiß, welche Übersetzungen, Slots, seiteneigenen Blockbäume, Assets und Revisionsbeziehungen mit ihm übertragen werden. Eine Seite ist mehr als der Stammknoten eines Komponentenarrays.

Ein Layout definiert, welche Bereiche eine Seite haben kann und wie diese Bereiche zur öffentlichen Shell gehören. Ein Standardlayout könnte eine Kopfzeile, einen Hauptbereich und eine Fußzeile umfassen; Ein Dokumentationslayout kann eine Seitenleiste hinzufügen.

Das Layout kann Reihenfolge, semantische Wrapper-Elemente, Wrapper-Klassen und eine body-Klasse definieren. Es besitzt die äußere Struktur, in der Inhalte gerendert werden, sodass Blöcke die Frage nicht lösen müssen: Was für eine Seitenhülle bin ich darin?

Eine Dokumentationsseitenleiste sollte nicht vorhanden sein, da ein Inhaltsblock zufällig einen Seitenleisten-Wrapper ausgegeben hat. Das Dokumentlayout besitzt diesen Bereich. Darin platzierte Blöcke bleiben Inhalt und werden nicht heimlich zur Seitenarchitektur.

Es gibt Kosten: Die Änderung eines Layouts ist strukturell und nicht nur visuell. WebBlocks löscht oder schreibt vorhandene Seitenbereiche daher nicht stillschweigend um, wenn sich eine Layoutauswahl ändert. Fehlende Slots können explizit hinzugefügt werden, während zusätzliche Slots gemeldet und beibehalten werden.

Ein Slot verbindet das strukturelle Versprechen des Layouts mit einer bestimmten Seite. Namen wie header, main, sidebar und footer haben eine Bedeutung, die über die Position hinausgeht. Der öffentliche Renderer kann einen semantischen Wrapper für die Region auswählen und Tools können ihn ansprechen, ohne zu erraten, wo er sich in einem JSON-Baum befindet.

Ein WebBlocks-Seitenslot hat eine explizite Quelle: page rendert Blöcke, die dieser Seite gehören, shared_slot rendert einen kompatiblen, standortbezogenen wiederverwendbaren Blockbaum und disabled behält die Region bei, rendert jedoch keine Blöcke darin.

Die Wiederverwendung ist daher eher eine Referenz als eine Kopie. Ein gemeinsam genutzter Header kann einmal aktualisiert und von jeder Seite gerendert werden, die darauf verweist. Die umfassenderen Auswirkungen bleiben sichtbar: Shared Slots verfügen über eigene Revisionen und einen eigenen Veröffentlichungsworkflow.

Die konsumierende Seite besitzt weiterhin den Slot-Wrapper. Ein Shared Slot trägt nur zum inneren Blockbaum bei und verhindert so, dass wiederverwendbarer Inhalt eine zweite Seiten-Shell in die Seite einbringt, die ihn konsumiert.

Blöcke sind die in einem Slot platzierten Redaktionseinheiten. Ein Block kann eine Überschrift, Rich Text, ein Bild, eine Navigation, eine Galerie oder ein Layoutprimitiv wie einen Stapel oder ein Raster darstellen. Unterstützte Blöcke können untergeordnete Blöcke enthalten, sodass Inhalte innerhalb eines Slots weiterhin einen Baum bilden können.

Die wichtige Einschränkung besteht darin, welche Blöcke nicht besitzen. Ein Block sollte nicht über die Seitenroute, den Workflow-Status oder die äußere Hülle entscheiden. Es besitzt seine Inhalte, Übersetzungen, Einstellungen, Beziehungen und Darstellung innerhalb der ihm zugewiesenen Region.

Das verbessert die Validierung. Eine Überschrift hat einen anderen Vertrag als eine Galerie. Ein Automatisierungstool kann typisierte Schemata erkennen, anstatt ein uneingeschränktes Seitendokument zu bearbeiten. Durch Rendering und Migration können Beziehungen überprüft werden, anstatt einen Blob zurückzuentwickeln.

Relationaler Speicher ist JSON nicht automatisch überlegen. Es macht einige Integritätsregeln und Migrationen klarer und führt gleichzeitig mehr Tabellen und Verknüpfungen ein. WebBlocks akzeptiert diese Kosten, da die explizite Eigentümerschaft für seine Multisite-, Lokalisierungs-, Revisions- und Automatisierungsworkflows von Bedeutung ist.

Betrachten Sie eine Installationsseite auf einer Dokumentationsseite:

Jede Änderung hat nun einen natürlichen Eigentümer. Das Ändern von /docs/installation gehört zum Seitenübersetzungs- und Routing-Workflow. Das Hinzufügen einer Strukturschiene gehört zum Layout. Das Ersetzen der Dokumentationsnavigation gehört zum Seitenleisten-Slot oder zu dessen Shared Slot. Das Bearbeiten eines Installationsbefehls gehört zum Codeblock.

Die Hierarchie ist nützlich, da sie sowohl Personen als auch Tools sagt, wo eine Änderung hingehört.

Eine klare Architektur garantiert keinen klaren Editor. Wenn jemand jedes Mal, wenn er einen Satz korrigieren möchte, manuell zu Seite -> Layout -> Slot -> Block navigieren muss, gerät das Modell in den Workflow. Durch Suche, nützliche Zusammenfassungen, direkte Bearbeitungslinks und sinnvolle Standardeinstellungen sollten Routineaufgaben Ebenen überspringen können, ohne sie aus dem System zu löschen.

Das Modell kann auch überdimensioniert werden. Eine Site mit einer festen Vorlage und einer Handvoll Feldern profitiert möglicherweise nicht von konfigurierbaren Layouts oder wiederverwendbaren Slot-Bäumen. Ein typisiertes Seitenmodell oder ein einfaches Markdown-Dokument ist möglicherweise das bessere Werkzeug.

Vier Fragen helfen dabei, zu testen, ob eine Ebene ihren Platz verdient:

1. Besitzt es eine bestimmte Art von Veränderung?
2. Kann diese Änderung unabhängig validiert werden?
3. Verhindert die Grenze einen wirklich ungültigen Zustand?
4. Kann durch routinemäßige Bearbeitung vermieden werden, dass die gesamten Komplexitätskosten bezahlt werden?

Wenn die Antwort auf die ersten drei Fragen „Nein“ lautet, handelt es sich möglicherweise um eine Zeremonie. Wenn die Antwort auf die vierte Frage „Nein“ lautet, ist die Architektur möglicherweise solide, während das Produkterlebnis noch verbessert werden muss.

Page -> Layout -> Slot -> Block wird nicht als neue Erfindung dargestellt. Regionen, Komponenten und strukturierte Inhalte gibt es in CMS-Produkten schon seit langem.

Der Punkt ist das explizite Eigentum. Seiten besitzen eine eigene Identität und einen eigenen Workflow. Layouts besitzen die Shell. Slots besitzen eine benannte Platzierung und Inhaltsquelle. Blockiert eigene Inhalte.

Diese Grenzen verdienen ihren Platz, wenn in einem von ihnen eine Veränderung stattfinden kann, ohne dass die anderen dazu gezwungen werden, so zu tun, als hätten sie sich ebenfalls verändert.

Wo ziehen Sie die Grenze zwischen Seitenstruktur und Inhalt in einem blockbasierten CMS – und welche Grenze verursacht die größte Reibung für Redakteure?