Relier les blocs CMS aux données dynamiques des plugins

Un plugin de catalogue, de commerce, d’événements ou d’actualités possède souvent des données métier utiles. Cela ne signifie pas qu’il doit aussi posséder la mise en page et le balisage public servant à les présenter.

Les sources de contenu de WebBlocks CMS séparent ces responsabilités. Un plugin expose des enregistrements typés ; les éditeurs les relient aux champs familiers des blocs CMS. La page conserve le contrôle de la composition, de la traduction, de l’aperçu et du rendu.

Une source de contenu répond quelles données sont disponibles. Un bloc répond comment ces données sont présentées. La page et son arborescence d'emplacements répondent où elle apparaît.

Cela permet à un plugin de réutiliser le comportement principal de l'en-tête, du texte enrichi, de l'image, du bouton, de la liste de liens, de la grille, de la pile et du curseur au lieu de fournir un autre ensemble parallèle de moteurs de rendu.

Modifiez un bloc pris en charge et ouvrez son onglet Settings. Sous Content source, chaque champ compatible peut conserver la valeur littérale saisie dans Block Fields ou sélectionner une source de plugin, un enregistrement stable et un champ déclaré.

Par exemple, un titre d'en-tête peut être connecté à un champ de texte à partir d'une entrée de catalogue. Les éditeurs choisissent la relation dans une liste ; aucune expression contraignante n’est tapée à la main.

La valeur du bloc d'origine reste importante : c'est la solution de repli éditoriale. Si le plugin est désactivé, la source disparaît, l'enregistrement ne peut pas être résolu ou la valeur résolue est vide, la page publique continue de restituer la valeur éditoriale stockée.

Les sources de collection gèrent des listes d'enregistrements. Ajoutez un conteneur compatible avec la collection tel que Grid ou Stack, créez un enfant direct comme modèle visuel, puis sélectionnez la collection et l'enfant à répéter.

Vous pouvez définir une limite d'enregistrement, filtrer sur un champ déclaré, trier dans les deux sens et décider si un résultat vide ou une erreur de résolution masque le modèle ou affiche sa solution de secours éditoriale.

Ouvrir un descendant pris en charge dans le modèle choisi. Ses options Content source incluent désormais Current collection item. Connectez le titre, la description, l'image ou le lien aux champs compatibles de cet enregistrement actuel.

Au moment du rendu, le CMS clone le sous-arbre du modèle une fois pour chaque enregistrement résolu et fournit cet enregistrement comme élément actuel. Les autres enfants dans le conteneur restent dans le contenu éditorial manuel et conservent leur position.

Les liaisons d'entité couvrent actuellement les titres d'en-tête ; Contenu en texte brut et en texte enrichi ; Source de l'image, légende, texte alternatif et lien ; Étiquettes et URL des boutons et des liens de bouton ; et le titre, le texte secondaire, la description et l'URL de l'élément de liste de liens.

La prise en charge de la collection est pilotée par contrat. La section principale, le conteneur, la pile, le cluster, la grille et la diapositive peuvent répéter des enfants directs valides. Le curseur répète la diapositive ; Les colonnes répètent l'élément de colonne ; La grille de fonctionnalités répète l'élément de fonctionnalité ou l'élément de colonne ; et la liste de liens répète l'élément de la liste de liens. Les conteneurs structurels qui produiraient des compositions non valides n'annoncent pas la prise en charge des collections.

Un plug-in activé enregistre soit une source d'entité, soit une source de collection avec un handle d'espace de noms, un résolveur et des définitions de champs typées. Les résolveurs d'entités renvoient des choix d'éditeur sécurisés et un enregistrement pour une clé stable. Les résolveurs de collection renvoient des enregistrements itérables ; les grandes sources peuvent implémenter le contrat interrogeable afin que le filtrage, le tri, les limites, les totaux et les fenêtres de page restent dans la base de données ou dans l'API en amont.

Les données restreintes peuvent associer une stratégie d'accès. Les sources peuvent également opter pour la mise en cache limitée et invalider leurs variantes mises en cache après les écritures du domaine. La sortie du résolveur ne devient jamais la source de vérité du CMS : les révisions et les transferts stockent la configuration de liaison et la solution de secours éditoriale normale, et non la sortie exécutable.

La partie utile de cette conception n'est pas seulement que les données peuvent être dynamiques. C'est que le comportement d'échec est explicite. Les enregistrements manquants, les plugins désactivés, les refus d'accès, les collections vides et les exceptions du résolveur n'ont pas besoin de supprimer la page.

Les éditeurs conservent une solution de secours visible, le panneau Paramètres signale les sources ou les champs manquants et le moteur de rendu public peut continuer à diffuser un contenu cohérent pendant que l'intégration est réparée.

Pour les contrats de développeur complets et les formes Internal Content API, lisez Content Sources and Block Field Bindings.