Aller au contenu
EnglishFrançais

Définition de type de contenu

Une définition de type de contenu (Content type definition) est la déclaration technique d’un type de contenu. Elle précise un espace de noms (un préfixe qui évite les doublons de noms), un nom, des propriétés (les champs) et des options qui s’appliquent aux contenus fondés sur ce type. Dans Jahia, elle s’écrit avec une syntaxe dédiée, dans un fichier texte à l’extension .cnd, livré dans un module.

Définition et fonctionnement

Pour une équipe projet, la définition est un contrat. Elle fixe ce que les contributeurs pourront saisir, quels champs seront obligatoires ou traduisibles et ce qu’une application pourra lire via l’API. C’est aussi à partir d’elle que Jahia génère le formulaire de Content Editor, sans qu’aucun écran de saisie soit dessiné à la main. Un changement de définition se répercute donc sur la saisie, l’affichage et l’API.

Concrètement, un type se déclare sur une ligne sous la forme [espace:nom] et hérite du type de base jnt:content, dont il reprend les caractéristiques communes. L’ajout du mixin jmix:editorialContent (un mixin est un ensemble de propriétés que l’on greffe sur un type) le rend disponible pour les contributeurs. Chaque propriété a un nom et un type de valeur (texte, booléen oui/non, date, nombre, référence vers un autre contenu) et peut recevoir des attributs (obligatoire, traduisible ou primaire), ce dernier désignant la propriété utilisée comme nom affiché. Les mixins regroupent des propriétés réutilisables, qui apparaissent comme des groupes de champs (fieldsets) dans le formulaire.

Documentation Academy : créer un type de contenu

Termes liés : Type de contenu · Propriété (contenu) · Content item · Nom affiché · Content Editor · Champ

Ressources sur ce terme

La définition de type de contenu et le type de contenu : les différences

La définition se distingue du type de contenu (le modèle qu’elle décrit) et des fichiers qui ajustent l’apparence du formulaire.

La définition de type de contenu et ses voisins
NotionCe qui la distingue
Type de contenuLe type est le modèle métier (une offre d’emploi, un produit). La définition est son écriture technique dans le fichier .cnd.
Organisation du formulaire (JSON)Des fichiers JSON livrés dans un module ajustent le formulaire : ordre, libellés, aides, sections. Ils modifient des champs déclarés dans la définition sans pouvoir en créer de nouveaux.
Propriété (contenu)La propriété est une ligne de la définition : un attribut nommé, avec son type de valeur et ses contraintes.

La définition de type de contenu en pratique

Avant de livrer un nouveau type "Actualité", l’intégrateur (l’équipe qui développe le site) partage la liste des propriétés prévues avec l’équipe éditoriale : titre (obligatoire, traduisible), chapeau, image, date, auteur. L’équipe signale qu’il manque un champ "Thème" pour filtrer les listes et que l’auteur n’a pas besoin d’être traduit. Corriger à ce stade prend quelques minutes.

Cette relecture évite le cas le plus coûteux, celui où l’on découvre après la mise en ligne qu’un champ indispensable manque ou qu’un champ n’a pas été déclaré traduisible.

Questions fréquentes

Modifier une définition de type de contenu demande-t-il un déploiement ?

Une modification de définition passe par une nouvelle version du module, puisque les définitions sont livrées dans des modules déployés sur la plateforme. Elle se répercute ensuite sur le formulaire de saisie, sur les vues et sur l’API. Pour des contenus déjà saisis, une modification de structure se prépare avec l’intégrateur, afin de vérifier son effet sur l’existant.

Pourquoi les définitions de types sont-elles rangées dans un fichier texte du module ?

La définition fait partie du code du projet. Rangée dans un module, elle se versionne, se relit et se déploie avec les vues et le reste du code, d’un environnement à l’autre. Les contributeurs n’en voient que le résultat, un formulaire généré automatiquement. La notation CND (Compact Namespace and Node Type Definition) est par ailleurs définie par la spécification JCR 2.0 (JSR 283, 2009), sur laquelle repose Jahia.

Qui doit relire une définition avant son développement ?

L’intégrateur l’écrit, mais l’équipe éditoriale gagne à relire la liste des champs prévus (noms, caractère obligatoire, traduction, valeurs attendues). Les responsables digitaux vérifient de leur côté ce que les listes, la recherche et l’API devront exploiter. Une relecture croisée au cadrage coûte peu et évite des reprises après la mise en ligne.