Page, mise en page, slot et bloc : l’utilité de chaque séparation

Le modèle de contenu principal WebBlocks CMS tient sur une seule ligne :

Page -> Layout -> Slots -> Blocks

Cela peut ressembler à une hiérarchie utile ou à une cérémonie inutile. Pourquoi ne pas stocker une page sous forme d'arborescence de composants et la restituer ? Cette approche est valable pour de nombreux produits. Quatre couches explicites ne gagnent leur place que lorsque chacune est propriétaire d’un type de changement différent.

Une page répond aux questions sur le document en tant qu'objet publiable : quel site en est propriétaire, quel est son itinéraire public dans chaque paramètre régional, s'il est en brouillon, en révision ou publié, quelle mise en page il utilise et quelles métadonnées, ressources et historique de révision lui appartiennent.

Ces problèmes subsistent lorsque le contenu visible change. Remplacer un héros, déplacer un paragraphe ou ajouter une galerie ne doit pas créer une nouvelle identité de routage.

L'inverse est également utile. Le déplacement ou la duplication d’une page peut être traité comme une opération de page contrôlée. Le système sait quelles traductions, emplacements, arborescences de blocs appartenant à la page, ressources et relations de révision l'accompagnent. Une page est plus que le nœud racine d’un tableau de composants.

Une mise en page définit les régions qu'une page peut avoir et comment ces régions appartiennent au shell public. Une mise en page par défaut peut fournir un en-tête, une région principale et un pied de page ; une mise en page de documentation peut ajouter une barre latérale.

La mise en page peut définir un ordre, des éléments d'emballage sémantiques, des classes d'emballage et une classe de l’élément body. Il possède la structure externe dans laquelle le contenu est restitué, les blocs n'ont donc pas à résoudre la question : Dans quel type de shell de page suis-je à l'intérieur ?

Une barre latérale de documentation ne devrait pas exister car un bloc de contenu émettait un wrapper de barre latérale. La mise en page des documents est propriétaire de cette région. Les blocs placés à l’intérieur restent du contenu plutôt que de devenir secrètement une architecture de page.

Il y a un coût : changer une mise en page est structurel, pas seulement visuel. WebBlocks ne supprime donc pas ou ne réécrit pas silencieusement les emplacements de page existants lorsqu'une sélection de mise en page change. Les emplacements manquants peuvent être ajoutés explicitement, tandis que les emplacements supplémentaires sont signalés et préservés.

Un emplacement relie la promesse structurelle de la mise en page à une page particulière. Des noms tels que header, main, sidebar et footer ont une signification au-delà de leur position. Le moteur de rendu public peut choisir un wrapper sémantique pour la région, et les outils peuvent le traiter sans deviner où il se situe dans une arborescence JSON.

Un emplacement de page WebBlocks a une source explicite : page restitue les blocs appartenant à cette page, shared_slot restitue une arborescence de blocs réutilisables compatible à l'échelle du site et disabled préserve la région sans restituer aucun bloc à l'intérieur.

La réutilisation est donc une référence plutôt qu'une copie. Un en-tête partagé peut être mis à jour une fois et affiché par chaque page qui y fait référence. L'impact plus large reste visible : les Shared Slots ont leur propre flux de révision et de publication.

La page consommatrice possède toujours le wrapper d'emplacement. Un Shared Slot contribue uniquement à l'arborescence des blocs interne, empêchant le contenu réutilisable d'introduire un deuxième shell de page dans la page qui le consomme.

Les blocs sont les unités éditoriales placées dans un emplacement. Un bloc peut représenter un titre, un texte enrichi, une image, une navigation, une galerie ou une primitive de mise en page telle qu'une pile ou une grille. Les blocs pris en charge peuvent contenir des blocs enfants, de sorte que le contenu à l'intérieur d'un emplacement peut toujours former une arborescence.

La contrainte importante concerne ce que les blocs ne possèdent pas. Un bloc ne doit pas décider de l'itinéraire de la page, de l'état du flux de travail ou de l'enveloppe externe. Il est propriétaire de son contenu, de ses traductions, de ses paramètres, de ses relations et de son rendu dans la région qui lui a été attribuée.

Cela améliore la validation. Une rubrique a un contrat différent d’une galerie. Un outil d'automatisation peut découvrir des schémas saisis plutôt que de modifier un document de page sans restriction. Le rendu et la migration peuvent inspecter les relations au lieu de procéder à une ingénierie inverse d'un blob.

Le stockage relationnel n'est pas automatiquement supérieur à JSON. Cela rend certaines règles d'intégrité et migrations plus claires tout en introduisant davantage de tables et de jointures. WebBlocks accepte ce coût car la propriété explicite est importante pour ses flux de travail multisites, de localisation, de révision et d'automatisation.

Considérons une page d'installation dans un site de documentation :

Chaque modification a désormais un propriétaire naturel. La modification de /docs/installation appartient au workflow de traduction et de routage des pages. L'ajout d'un rail structurel fait partie du tracé. Le remplacement de la navigation dans la documentation appartient à l'emplacement de la barre latérale ou à son Shared Slot. La modification d'une commande d'installation appartient au bloc Code.

La hiérarchie est utile car elle indique aux personnes et aux outils à quoi appartient un changement.

Une architecture claire ne garantit pas un éditeur clair. Si quelqu'un doit naviguer manuellement Page -> Mise en page -> Emplacement -> Bloc à chaque fois qu'il souhaite corriger une phrase, le modèle s'infiltre dans le flux de travail. La recherche, les résumés utiles, les liens d'édition directs et les valeurs par défaut raisonnables devraient permettre aux tâches de routine de sauter des couches sans les effacer du système.

Le modèle peut également devenir trop conçu. Un site avec un modèle fixe et une poignée de champs peut ne pas bénéficier de mises en page configurables ou d'arborescences d'emplacements réutilisables. Un modèle de page dactylographié ou un simple document Markdown peut être le meilleur outil.

Quatre questions permettent de vérifier si une couche mérite sa place :

1. Propose-t-il un type de changement distinct ?
2. Cette modification peut-elle être validée indépendamment ?
3. La limite empêche-t-elle un état réellement invalide ?
4. L'édition de routine peut-elle éviter de payer le coût total de la complexité ?

Si la réponse aux trois premières est non, la couche peut être une cérémonie. Si la réponse à la quatrième question est non, l’architecture peut être solide alors que l’expérience produit doit encore être améliorée.

Page -> Layout -> Slot -> Block n’est pas présenté comme une nouvelle invention. Les régions, les composants et le contenu structuré existent depuis longtemps dans les produits CMS.

Le point est la propriété explicite. Les pages possèdent leur identité et leur flux de travail. Les mises en page possèdent le shell. Les machines à sous possèdent un emplacement nommé et une source de contenu. Bloque son propre contenu.

Ces limites gagnent leur place lorsqu'un changement peut se produire à l'intérieur de l'une d'elles sans forcer les autres à prétendre qu'ils ont changé aussi.

Où tracez-vous la limite entre la structure des pages et le contenu dans un CMS basé sur des blocs, et quelle limite provoque le plus de frictions pour les éditeurs ?