Les pages sont faites de blocs, et les blocs ont besoin de données. Une partie vit dans l'instance de bloc elle-même - un titre, un paragraphe, une image. Le reste vit dans des collections structurées que vous définissez une fois et réutilisez partout : modèles, enregistrements, médias et formulaires.

Modèles et enregistrements

Un modèle est un schéma pour un type de contenu : un produit, un auteur, une offre d'emploi, une étude de cas. Un enregistrement est une entrée conforme à ce schéma. Les modèles vivent au niveau de l'espace de travail, pas d'une page : la même collection alimente donc autant de pages et de blocs que vous voulez.

Vous définissez les modèles dans l'espace de travail, pas dans le code du frontend. C'est l'inverse des schémas de blocs, qui sont du code et voyagent avec votre dépôt - la séparation est délibérée : la forme de l'UI dans le code, la forme des données dans cmssy.

Relier des enregistrements aux blocs

Les blocs récupèrent des enregistrements via un champ de relation. Une relation stocke des identifiants, pas des copies - l'API de diffusion les résout en enregistrements complets au moment du rendu, si bien qu'un enregistrement modifié une fois se met à jour partout où il apparaît.

• picked (par défaut) - l'éditeur choisit un enregistrement, ou plusieurs avec multiple: true. Une étude de cas mise en avant ; les trois offres d'une page tarifs.
• mode: "all" - le champ ne stocke rien ; le bloc reçoit tous les enregistrements du modèle, mis en forme par sort et limit. Parfait pour un index de blog ou une FAQ qui ne doit jamais être recurée.

C'est pourquoi un bloc "derniers articles" continue de fonctionner après l'ajout d'un article : il porte une requête, pas un instantané.

Médias

Images et fichiers vivent dans la médiathèque de l'espace de travail, organisée en dossiers. Les blocs référencent les médias par URL, et chaque envoi reçoit sa propre URL hachée : téléverser un remplacement ne met donc pas à jour les blocs qui pointent vers l'ancien fichier. Il n'existe pas de remplacement sur place : le remède est de re-pointer les blocs, un chercher-remplacer sur le contenu des blocs - exactement ce que le serveur MCP sait faire. Envois, dossiers et déplacements passent aussi par le serveur MCP, ce qui rend scriptable le travail média en masse.

Formulaires

Les formulaires se construisent visuellement dans l'espace de travail et sont rendus par le bloc auquel vous les rattachez. Les soumissions reviennent dans cmssy, où chacune porte un statut que vous faites avancer dans votre propre workflow.

La soumission est la seule écriture que votre frontend public peut effectuer sans jeton - elle passe par la mutation form.submit de l'API de diffusion. Tout le reste - créer un formulaire, lire les soumissions, changer un statut - exige un client autorisé.

Tout est multilingue

Chaque champ est multilingue par défaut. Le contenu est stocké indexé par code de langue : un enregistrement porte donc toutes ses traductions, et l'API de diffusion remet à votre frontend celle qui correspond à la locale active. Vous ne modélisez pas les traductions - vous les remplissez.