Déclaration et modification d'un type de contenu


Le CMS Ametys supporte différents types de contenus (article, actualité, galeries photos, FAQ, ...). Les types de contenus disponibles dépendent des extensions (plugins) utilisés.

Les types de contenus les plus couramment sont décrits dans le Manuel Utilisateur.

Un type de contenu est un point d'extension multiple. Un intégrateur peut créer des nouveaux type de contenus (séminaire, poste, etc) suivant vos besoins.

  1. Définition
    1. Les icônes ou glyphes
    2. Les attributs
      1. Déclaration simple
      2. Validation
      3. Widget de modification
      4. Attribut composite
      5. Les énumérations
      6. Restrictions
        1. Restriction en lecture ou lecture/écriture
        2. Restriction en lecture ou lecture/écriture en fonction d'un droit
        3. Restriction en lecture ou lecture/écriture en fonction d'un état du workflow
        4. Restrictions sur les composites multiples (repeater)
    3. Les vues
      1. Syntaxe historique
      2. Nouvelle syntaxe
    4. Les tags
    5. Héritage multiple
    6. Les types de contenus spécifiques
      1. Les rôles
      2. Les tables de référence
      3. Type de contenu privé
      4. Type de contenu abstrait
    7. Déclaration d'un nouveau type de contenu
    8. Définition dans le répertoire WEB-INF/param/content-types
    9. Exemple complet de déclaration d'un contenu simple
    10. Définition dans un plugin
  2. Le rendu graphique
  3. Modification d'un type de contenu existant
    1. Restriction en lecture ou lecture/écriture
    2. Restriction en lecture ou lecture/écriture en fonction d'un droit
    3. Restriction en lecture ou lecture/écriture en fonction d'un état du workflow

 

Définition

Un type de contenu est défini par:

  • Un identifiant unique
  • Un libellé
  • Une description
  • Des icônes de taille 16x16, 32x32 et 48x48 pixels
  • Un droit (optionnel) pour restreinte la création du type de contenu aux personnes ayant droit
  • Un jeu d'attributs (ex: titre, description, image, fichiers, date, ...) typés.
  • Des vues

Chaque vue définit la liste des attributs qui lui sont nécessaires, parmi les attributs du contenus. Par exemple, une vue "abstract" (résumé) aura besoin des attributs titre et illustration, tandis qu'une vue "main" (complète) aura besoin de l'ensemble des attributs.

Un type de contenu est un point d'extension de type org.ametys.cms.contenttype.ContentTypeExtensionPoint. Sa déclaration doit respecté le format XML suivant:

Format XML de déclaration d'un type de contenu

<extension point="org.ametys.cms.contenttype.ContentTypeExtensionPoint"
id="org.ametys.web.default.Content.article"
class="org.ametys.web.contenttype.WebContentType">

    <cms:content-type>
        <cms:label i18n="true">CONTENT_ARTICLE_LABEL</cms:label>
        <cms:description i18n="true">CONTENT_ARTICLE_DESCRIPTION</cms:description>
        <cms:default-title i18n="true">CONTENT_ARTICLE_DEFAULT_TITLE</cms:default-title>
        <cms:icons>
            <cms:small>img/content/article/icon-small.png</cms:small>
            <cms:medium>img/content/article/icon-medium.png</cms:medium>
            <cms:large>img/content/article/icon-large.png</cms:large>
        </cms:icons>

        <cms:right>Web_Right_Article_Create</cms:right>

<!-- Déclaration des attributs ici -->

<!-- Déclaration des vues ici -->

    </cms:content-type>
</extention>

Les icônes ou glyphes

Vous pouvez représenter votre de type de contenu soit :

  • par 3 icônes de taille 16x16, 32x32 et 48x48 pixels 
  • par un pictogramme (glyph)

Si vous choisissez un glyph, pensez à ajouter le fichier CSS dans lequel est défini le glyph.

<cms:icons>
    <cms:glyph>ametysicon-text70</cms:glyph>
</cms:icons>
<css>
    <file plugin="core-ui">font/ametys/AmetysIcon.css</file>
</css>

L'icône "medium", ainsi que le libellé et la description sont utilisées pour le menu "Ajouter un contenu"

<cms:icons>
    <cms:small>img/content/article/icon-small.png</cms:small>
    <cms:medium>img/content/article/icon-medium.png</cms:medium>
    <cms:large>img/content/article/icon-large.png</cms:large>
</cms:icons>

L'icône "small" est utilisée lors d'un l'insertion d'un contenu dans une page et dans les résultats du moteur de recherche.

L'icône "large" est à ce jour pas utilisée.

Les attributs

Les attributs sont des paramètres classiques comme décrits dans la page Généralités sur les paramètres avec quelques variations et éléments supplémentaires.

Déclaration simple

Comme tout paramètre, un attribut possède à minima un nom unique, libellé, une description et un type (string, date, long, ...) et se déclare comme suit dans la balise <cms:metadata>:

Exemple de déclaration d'un attribut "Titre" de type string, obligatoire

<cms:metadata name="title" type="string">
    <label i18n="true">CONTENT_ARTICLE_TITLE</label>
    <description i18n="true">CONTENT_ARTICLE_TITLE_DESC</description>
    <validation>
        <mandatory />
    </validation>
</cms:metadata>

Voir la liste des types disponibles pour un attribut.

Validation

L'instruction <validation> permet de définir des règles de validation sur un attribut:

  • <mandatory> pour rendre l'attribut obligatoire
  • <regexp> pour définir une expression régulière
  • <invalidText> pour personnaliser le message en cas de saisie incorrecte (expression régulière non respectée)
  • <custom-validator> classe java implémentant l'interface org.ametys.runtime.util.parameter.Validator pour définir son propre validateur
    • Par exemple org.ametys.runtime.plugins.core.util.parameter.TextValidator pour champ texte simple ou org.ametys.runtime.plugins.core.util.parameter.RichTextValidator pour champ riche, supportent une sous balise

      • <maxlength> pour un nombre de caractères maximums supporté

 

Exemple de validation pour un champ "adresse mail" obligatoire

<validation>
    <custom-validator class="org.ametys.runtime.plugins.core.util.parameter.TextValidator"> 
        <maxlength>60</maxlength>
        <mandatory/>
        <regexp>^(\w+)([\-+.][\w]+)*@(\w[\-\w]*\.){1,5}([A-Za-z0-9][A-Za-z0-9]+)$</regexp>
        <invalidText i18n="true">PLUGINS_WEB_REGEXP_INVALID_MAIL</invalidText>
    </custom-validator>
</validation>

Voir d'autres exemples sur la page Généralités sur les paramètres, chapitre "Validation".

Widget de modification

Il est possible de préciser un "widget" pour la modification de l'attribut. Par exemple, pour un attribut de type "string", on peut utiliser le widget "edition.textarea" pour modifier l'attribut sur plusieurs lignes.
L'utilisation d'un widget se fait au travers de la balise <widget> comme dans l'exemple ci-dessous:

Exemple d'utilisation d'un widget

<cms:metadata name="abstract" type="string">
    <label i18n="false">CONTENT_ARTICLE_ABSTRACT</label>
    <description i18n="true">CONTENT_ARTICLE_ABSTRACT_DESC</description>
    <widget>edition.textarea</widget>
</cms:metadata>

Voir la liste des widgets d'édition disponibles pour les attributs de contenus.

Attribut composite

Une attribut peut être "composite", c'est à dire elle-même composée d'autres attributs. Par exemple, une illustration est composée d'un fichier et d'un texte alternatif.

Exemple de déclaration d'un attribut composite

<cms:metadata name="illustration" type="composite">
    <label i18n="true">CONTENT_ARTICLE_ILLUSTRATION</label>
    <description i18n="true">CONTENT_ARTICLE_ILLUSTRATION_DESC</description>
    <cms:metadata name="image" type="file">
        <label i18n="true">CONTENT_ARTICLE_IMAGE</label>
        <description i18n="true">CONTENT_ARTICLE_IMAGE_DESC</description>
        <widget>external-or-resource-image</widget>
    </cms:metadata>
    <cms:metadata name="alt-text" type="string">
        <label i18n="true">CONTENT_ARTICLE_IMAGE_ALT</label>
        <description i18n="true">CONTENT_ARTICLE_IMAGE_ALT_DESC</description>
    </cms:metadata>
</cms:metadata>

Il est possible de définir des attributs composites multiples, c'est à dire pouvant être répétés autant de fois que souhaité. Par exemple pour pouvoir ajouter 0 à n pièces jointes à un contenu. C'est ce qu'on appelle des "repeater".

Exemple de déclaration d'un repeater

<cms:repeater name="attachments" initial-size="0">
    <label i18n="true">PLUGINS_ODF_PROGRAM_ATTACHED_FILES</label>
    <description i18n="true">PLUGINS_ODF_PROGRAM_ATTACHED_FILES_DESC</description>
    <cms:add-label i18n="true">PLUGINS_ODF_PROGRAM_ATTACHED_FILE_ADD</cms:add-label>
    <cms:del-label i18n="true">PLUGINS_ODF_PROGRAM_ATTACHED_FILE_DEL</cms:del-label>
    <cms:metadata name="attachment" type="file">
        <label i18n="true">PLUGINS_ODF_PROGRAM_ATTACHED_FILE</label>
        <description i18n="true">PLUGINS_ODF_PROGRAM_ATTACHED_FILE_DESC</description> 
    </cms:metadata> 
    <cms:metadata name="attachment-text" type="string">
        <label i18n="true">PLUGINS_ODF_PROGRAM_ATTACHED_FILE_TEXT</label>
        <description i18n="true">PLUGINS_ODF_PROGRAM_ATTACHED_FILE_TEXT_DESC</description> 
    </cms:metadata> 
</cms:repeater>

- cms:add-label permet de redéfinir le tooltip du bouton d'ajout ("Ajouter une entrée" par défaut)
- cms:del-label permet de redéfinir le tooltip du bouton de suppression ("Supprimer une entrée" par défaut)

Les énumérations

Un attribut énuméré peut prendre une valeur parmi une liste définie : une liste statique ou dynamique.

Voir les généralité sur les paramètres pour l'écriture d'une liste statique de valeurs.

Restrictions

Il est possible de définir des restrictions en lecture et/ou écriture sur les attributs.

Les restrictions peuvent être de plusieurs sorte :

  • restriction en lecture ou lecture/écriture
  • restriction en lecture ou lecture/écriture en fonction d'un droit
  • restriction en lecture ou lecture/écriture en fonction d'un état de workflow
Restriction en lecture ou lecture/écriture
<cms:metadata name="typology" type="string">
    <label i18n="false">Typologie</label>
    <description i18n="false">Typologie de projet</description>
    <cms:restrict-to>
        <cms:cannot read-write-direction="write"/>
    </cms:restrict-to>
</cms:metadata>

Dans cette configuration, si l'attribut read-write-direction vaut:

  • write : le contributeur peut voir l'attribut, sans pouvoir le modifier (accès en lecture seule)
  • read : le contributeur ne peut ni voir, ni modifier l'attribut
Restriction en lecture ou lecture/écriture en fonction d'un droit
<cms:metadata name="typology" type="string">
    <label i18n="false">Typologie</label>
    <description i18n="false">Typologie de projet</description>
    <cms:restrict-to>
        <cms:right id="Web_Right_SuperEdit" read-write-direction="write"/>
    </cms:restrict-to>
</cms:metadata>

Dans cette configuration,

  • la balise <right> détermine le droit que doit posséder le contributeur
  • si l'attribut read-write-direction vaut :
    • write : le contributeur ne peut modifier l'attribut que s'il possède le droit "Web_Right_SuperEdit", sinon, il aura accès à l'attribut uniquement en lecture
    • read : le contributeur aura accès en lecture/écriture à l'attribut uniquement s'il possède le droit "Web_Right_SuperEdit"
Restriction en lecture ou lecture/écriture en fonction d'un état du workflow
<cms:metadata name="typology" type="string">
    <label i18n="false">Typologie</label>
    <description i18n="false">Typologie de projet</description>
    <cms:restrict-to>
        <cms:workflow step="2" read-write-direction="write"/>
        <cms:workflow step="3" read-write-direction="read"/>
    </cms:restrict-to>
</cms:metadata>

Dans cette configuration,

  • la balise <workflow> détermine l'état de workflow concerné par la restriction
  • si l'attribut read-write-direction vaut :
    • write : le contributeur ne peut modifier l'attribut que si le contenu est actuellement dans l'état de workflow défini
    • read : le contributeur aura accès à l'attribut en lecture/écriture que si le contenu est actuellement dans l'état de workflow défini
Restrictions sur les composites multiples (repeater)

Les restrictions décrites ci-dessus peuvent s'appliquer également aux repeaters

<cms:repeater name="photos" initial-size="0">
    <label i18n="false">Photos</label>
    <description i18n="false">Photos</description>
    <cms:add-label i18n="false">Ajouter une photos</cms:add-label>
    <cms:del-label i18n="false">Supprimer la photos</cms:del-label>
    <cms:restrict-to>
        <cms:right read-write-direction="write" id="Web_Right_SuperEdit"/>
    </cms:restrict-to>
    <cms:metadata name="image" type="file">
        <label i18n="false">Fichier</label>
        <description i18n="false">Fichier image</description>
    </cms:metadata>
    <cms:metadata name="legend" type="string">
        <label i18n="false">Légende</label>
        <description i18n="false">Légende</description>
    </cms:metadata>
</cms:repeater>

 

 

Si un contributeur n'a pas accès en écriture à un repeater, alors il ne pourra pas ni ajouter, ni supprimer, ni déplacer les entrées du repeater

Les vues

Une vue est un ensemble d'attributs. Chaque vue fait référence aux attributs déclarés nécessaires à son affichage.

Depuis la version d'Ametys 4.4, deux syntaxes de vues cohabitent : la syntaxe historique et une nouvelle syntaxe, toutes deux décrites ci-après. Il est donc possible de déclarer une vue de type main avec la syntaxe historique, et de déclarer une vue de type abstract avec la nouvelle. 

Pour une version d'Ametys antérieure à la 4.4, une seule syntaxe est disponible : la syntaxe historique. 

Syntaxe historique

Une vue est déclarée comme suit, dans la balise <cms:metadata-set> :

Exemple de vue "main"

<cms:metadata-set name="main" type="view">
    <cms:fieldset role="fieldset">
        <cms:label>group1</cms:label>
        <cms:metadata-ref name="title" />
        <cms:metadata-ref name="document-subtitle" />
        <cms:metadata-ref name="illustration">
            <cms:metadata-ref name="image" />
            <cms:metadata-ref name="alt-text" />
        </cms:metadata-ref>
        <cms:metadata-ref name="abstract" />
        <cms:metadata-ref name="content" />
    </cms:fieldset>
    <cms:label i18n="true">PLUGINS_WEB_VIEW_MAIN</cms:label>
    <cms:description i18n="true">PLUGINS_WEB_VIEW_MAIN_DESC</cms:description>
</cms:metadata-set>

Exemple de vue "abstract"

<cms:metadata-set name="abstract" type="view">
    <cms:fieldset role="fieldset">
        <cms:label>group1</cms:label>
        <cms:metadata-ref name="title" />
        <cms:metadata-ref name="document-subtitle" />
        <cms:metadata-ref name="illustration">
            <cms:metadata-ref name="image" />
            <cms:metadata-ref name="alt-text" />
        </cms:metadata-ref>
        <cms:metadata-ref name="abstract" />
        <cms:metadata-ref name="content" />
    </cms:fieldset>
    <cms:label i18n="true">PLUGINS_WEB_VIEW_ABSTRACT</cms:label>
    <cms:description i18n="true">PLUGINS_WEB_VIEW_ABSTRACT_DESC</cms:description>
</cms:metadata-set>
  • Sur la balise <cms:metadata-set>  : 
    • L'attribut name est le nom de vue (ex: main, abstract, link, details, search, ...)
    • L'attribut type définit le type de vue: view pour une vue destinée à l'affichage, edition pour une vue de modification
    • L'attribut internal, optionnel permet de "privatiser" la vue, c'est à dire la rendre invisible pour le contributeur. C'est le cas par exemple de la vue "details" utilisée pour l'indexation des attributs pour la recherche.
  • La balise  cms:fieldset définit le groupement d'attributs
    • L'attribut role définit le type de groupement : 
      • La valeur tab représente un groupement par onglets
      • La valeur fieldset correspond à un liseré représentant le groupement
      • Cet attribut est optionnel : si celui-ci n'est pas défini, il prend la valeur tab par défaut pour le premier niveau de groupement, et la valeur fieldset par défaut pour les niveaux inférieurs. 
    • La balise cms:label définit le libellé du groupe
    • La balise cms:description définit la description du groupe
  • Les balises cms:metadata-ref font référence à un attribut décrit dans le type de contenu, en indiquant son nom
  • La balise  cms:label définit le libellé de la vue
  • La balise cms:description définit la description de la vue

Les vues obligatoires et optionnelles 

Vous pouvez définir autant de vues que vous souhaitez. En revanche certaines vues sont obligatoires et doivent être déclarées pour tous types de contenus:

  • la vue "main" de type "view" (obligatoire) utilisée pour le rendu du contenu dans sa vue "complète"
  • la vue "default-edition" de type "edition" (optionnelle) utilisée pour la modification du contenu
  • la vue "abstract" de type "view" (optionnelle) utilisée pour le rendu du contenu dans sa vue "résumé" (dans une remontée de contenu par exemple)
  • la vue "link" de type "view" (optionnelle)  utilisée pour le rendu du contenu dans sa vue "lien"
  • la vue "details" de type "view" (obligatoire) pour définir les attributs à afficher dans l'outil "Propriétés du contenu"
  • la vue "index" (optionnelle) pour définir les attributs qui seront indexés par le moteur de recherche

Pour être rendue, une vue est liée à un fichier XSL.  Les données XML en entrée de cet XSL correspondent aux attributs déclarés dans cette vue.

Nouvelle syntaxe

Cette nouvelle syntaxe est disponible à partir de la version Ametys 4.4

Une vue est déclarée comme suit, dans la balise <cms:view> :

Exemple de vue "main"

<cms:view name="main">
    <cms:group name="group1" role="tab">
        <cms:attribute-ref name="title" />
        <cms:attribute-ref name="document-subtitle" />
            <cms:attribute-ref name="illustration">
            <cms:attribute-ref name="image" />
            <cms:attribute-ref name="alt-text" />
        </cms:attribute-ref>
        <cms:attribute-ref name="abstract" />
        <cms:attribute-ref name="content" />
        <cms:label i18n="true">PLUGINS_WEB_VIEW_MAIN</cms:label>
        <cms:description i18n="true">PLUGINS_WEB_VIEW_MAIN_DESC</cms:description>
    </cms:group>
</cms:view>

Exemple de vue "abstract"

<cms:view name="abstract">
    <cms:group name="group1" role="tab">
        <cms:attribute-ref name="title" />
        <cms:attribute-ref name="document-subtitle" />
        <cms:attribute-ref name="illustration">
            <cms:attribute-ref name="image" />
            <cms:attribute-ref name="alt-text" />
        </cms:attribute-ref>
        <cms:attribute-ref name="abstract" />
        <cms:attribute-ref name="content" />
        <cms:label i18n="true">PLUGINS_WEB_VIEW_ABSTRACT</cms:label>
        <cms:description i18n="true">PLUGINS_WEB_VIEW_ABSTRACT_DESC</cms:description>
    </cms:group>
</cms:view>
  • Sur la balise <cms:view>  : 
    • L'attribut name est le nom de vue (ex: main, abstract, link, details, search, ...)
    • L'attribut internal, optionnel permet de "privatiser" la vue, c'est à dire la rendre invisible pour le contributeur. C'est le cas par exemple de la vue "details" utilisée pour l'indexation des attributs pour la recherche.
  • La balise  cms:group permet de regrouper les différents attributs de la vue. 
    • L'attribut name correspond au nom du groupe, cet attribut est optionnel
    • L'attribut role définit le type de groupement : 
      • La valeur tab représente un groupement par onglets
      • La valeur fieldset correspond à un liseré représentant le groupement
      • Cet attribut est optionnel : si celui-ci n'est pas défini, il prend la valeur tab par défaut pour le premier niveau de groupement, et la valeur fieldset par défaut pour les niveaux inférieurs. 
    • La balise cms:label définit le libellé du groupe
    • La balise cms:description définit la description du groupe
  • Les balises cms:attribute-ref font référence à un attribut décrit dans le type de contenu, en indiquant son nom
  • la balise  cms:label définit le libellé de la vue
  • la balise cms:description définit la description de la vue

Vues jointées

Cette nouvelle syntaxe de vue permet de réaliser des vues jointées (utiles pour les contenus liés); en voici les exemples :

Ajout de quelques attributs d'un contenu lié

Dans l'exemple ci-dessous, les attributs "att1" et "att2" du linked-content sont ajoutés à la vue

<cms:attribute-ref name="linked-content">        
    <cms:attribute-ref name="att1" />                
    <cms:attribute-ref name="att2" />         
</cms:attribute-ref>

Ajout de tous les attributs d'une vue

Dans l'exemple ci-dessous, tous les attributs présents dans la vue "abstract" du linked-content sont ajoutés à la vue

<cms:attribute-ref name="linked-content">
    <cms:view name="abstract" />
</cms:attribute-ref>

Ajout de tous les attributs d'une vue et d'autres attributs du contenu non présents dans la vue

Dans l'exemple ci-dessous :

  • tous les attributs présents dans la vue "abstract" du linked-content sont ajoutés à la vue
  • L'attribut 'att1' (non présent dans la vue abstract) est ajouté à la vue
<cms:attribute-ref name="linked-content">        
    <cms:view name="abstract" />                
    <cms:attribute-ref name="att1" />         
</cms:attribute-ref>

Ajout de tous les attributs du contenu lié

Dans l'exemple ci-dessous, tous les attributs définis dans le modèle du linked-content sont ajoutés à la vue

<cms:attribute-ref name="linked-content">
    <cms:attribute-ref name="*" />
</cms:attribute-ref>

Ajout de tous les attributs d'un composite (ou repeater)

Dans l'exemple ci-dessous, tous les attributs du composite "illustration" sont ajoutés à la vue. 

<cms:attribute-ref name="illustration">
    <cms:attribute-ref name="*" />
</cms:attribute-ref>

Cette syntaxe peut être utilisée avec les composites et les repeaters. 

Les vues obligatoires et optionnelles

De la même manière que pour la syntaxe historique, vous pouvez définir autant de vues que vous souhaitez. En revanche certaines vues sont obligatoires et doivent être déclarées pour tous types de contenus:

  • la vue "main" (obligatoire) utilisée pour le rendu et la modification du contenu dans sa vue "complète"
  • la vue "abstract" (optionnelle) utilisée pour le rendu du contenu dans sa vue "résumé" (dans une remontée de contenu par exemple)
  • la vue "link"(optionnelle)  utilisée pour le rendu du contenu dans sa vue "lien"
  • la vue "details" (obligatoire) pour définir les attributs à afficher dans l'outil "Propriétés du contenu"
  • la vue "index" (optionnelle) pour définir les attributs qui seront indexés par le moteur de recherche

Les tags

Les types de contenus peuvent recevoir des tags.

Les tags permettent des traitements spécifiques en Java.

Il existe 3 tags reconnus par toute application Ametys :

  • private : un type de contenu privé est un type de contenu qui ne peut être créé et qui n'apparait pas dans les moteurs de recherche par défaut.
  • reference-table: le type de contenu est une table de référence (voir plus loin)
  • mixin : type de contenu qui est sémantiquement un rôle (voir plus loin)

La déclaration de "tags" dans le type de contenu s'écrit :

<cms:tags>
    <cms:tag>reference-table</cms:tag>
    <cms:tag>private</cms:tag>
</cms:tags>

Les tags peuvent être hérités du type de contenu parent avec l'attribut inherited="true"

<cms:tags inherited="true"/>

Tags personnalisés

Vous pouvez ajouter vos propres tags.

  • Pas besoin de déclaration préalable

  • Nécessite du code java spécifique dans des outils spécifiques

Héritage multiple

Depuis Ametys v4, un type de contenu peut hériter d'un ou plusieurs types de contenus.

L'héritage permet de créer un nouveau de types de contenu :

  • à partir des attributs et des vues d’un ou plusieurs types existants
  • de compléter avec de nouveaux attributs
  • de modifier la définition d’un attribut existant
  • de modifier les vues existantes
  • de rajouter des nouveaux attributs et/ou vues

Par exemple, on peut imaginer un type de contenu "événement géolocalisé" qui étend le type "Actualité" pour y ajouter un attribut de type "geocode".

Une recherche sur les contenus de type "Actualités" renverra aussi bien des actualités que des événements géolocalisés.

Le fichier de définition correspondant à la définition du type "événement géolocalisé" serait :

<cms:content-type xmlns:cms="http://www.ametys.org/schema/cms" extends="org.ametys.plugins.news.Content.news">
    <cms:label i18n="true">plugin.myplugin:EVENT_LABEL</cms:label>
    <cms:description i18n="true">plugin.myplugin:EVENT_DESCRIPTION</cms:description>
    <cms:default-title i18n="true">plugin.myplugin:EVENT_DEFAULT_TITLE</cms:default-title>

    <cms:metadata name="geolocation" type="geocode">
        <label i18n="true">plugin.myplugin:EVENT_GEOLOCATION</label>
        <description i18n="true">plugin.myplugin:EVENT_GEOLOCATION_DESC</description>
    </cms:metadata>

    <cms:metadata-set name="main" type="view">
        <cms:include from-supertype="org.ametys.plugins.news.Content.news" />
        <cms:metadata-ref name="geolocation" />
    </cms:metadata-set>

    <cms:metadata-set name="main" type="edition">
        <cms:include from-supertype="org.ametys.plugins.news.Content.news" />
        <cms:metadata-ref name="geolocation" />
    </cms:metadata-set>
</cms:content-type>

Pour éviter de redéfinir entièrement la vue "main", l'instruction <cms:include from-supertype=".."> peut être utilisée pour inclure tous les attributs de la vue héritée.

Si vous voulez en revanche insérer le nouvel attribut dans un endroit spécifique du formulaire de modification, il sera nécessaire de redéfinir la vue.

Pour hériter de plusieurs type de contenus, les types de contenus hérités doivent être séparés par des virgules.

Restrictions

Les types de contenus spécifiques

Les rôles

Les rôles sont des types de contenus transversaux qui viennent compléter la sémantique d’un type de contenu.

Il n'est possible de créer un contenu à partir d'un rôle.

Par exemples :

  • Le rôle Dateable permet d’ajouter des dates à un type de contenu
  • Le rôle Localisable permet d’ajouter une adresse à un type de contenu
  • Actualité hérite de Article et ajoute le rôle Dateable
  • Evenement hérite de Actualité et ajoute le rôle Localisable

Une recherche de tous les contenus Dateable renverra aussi bien des Actualités que des Evenement .

Techniquement, un "rôle" très proche d’un type de contenu :

  • il se déclare de la même façon en spécifiant le tag « mixin » (voir plus haut le chapitre sur les tags)
  • il s’utilise avec l’héritage de type de contenus
  • ils peuvent aussi s’ajouter dynamiquement via l'IHM

Si on reprend l'exemple des événements géolocalisés plus haut, on peut imaginer une autre manière de faire en utilisant un rôle :

  • définition du rôle "content-type.Localisable"

    <cms:content-type xmlns:cms="http://www.ametys.org/schema/cms">
        <cms:label i18n="true">plugin.myplugin:LOCALISABLE_LABEL</cms:label>
        <cms:description i18n="true">plugin.myplugin:LOCALISABLE_DESCRIPTION</cms:description>
    
        <cms:tags>
            <cms:tag>mixin</cms:tag>
        </cms:tags>
    
        <cms:metadata name="geolocation" type="geocode">
            <label i18n="true">plugin.myplugin:EVENT_GEOLOCATION</label>
            <description i18n="true">plugin.myplugin:EVENT_GEOLOCATION_DESC</description>
        </cms:metadata>
    
        <cms:metadata-set name="main" type="view">
            <cms:metadata-ref name="geolocation" />
        </cms:metadata-set>
    
        <cms:metadata-set name="main" type="edition">
            <cms:metadata-ref name="geolocation" />
        </cms:metadata-set>
    </cms:content-type>
  • définition du type "Événement géolocalisé" qui hérite du type "Actualité" et "Localisable"

    <cms:content-type xmlns:cms="http://www.ametys.org/schema/cms" extends="org.ametys.plugins.news.Content.news,content-type.Localisable">
        <cms:label i18n="true">plugin.myplugin:EVENT_LABEL</cms:label>
        <cms:description i18n="true">plugin.myplugin:EVENT_DESCRIPTION</cms:description>
        <cms:default-title i18n="true">plugin.myplugin:EVENT_DEFAULT_TITLE</cms:default-title>
    
        <cms:metadata-set name="main" type="view">
            <cms:include from-supertype="org.ametys.plugins.news.Content.news" />
            <cms:include from-supertype="content-type.Localisable" />
        </cms:metadata-set>
    
        <cms:metadata-set name="main" type="edition">
            <cms:include from-supertype="org.ametys.plugins.news.Content.news" />
            <cms:include from-supertype="content-type.Localisable" />
        </cms:metadata-set>
    </cms:content-type>
    
    

     

Les tables de référence

Les tables de référence sont des types de contenus qui s’utilisent avec les outils de modification et de recherche dédiés.

Les types d'attributs autorisés sont limités à des attributs simple:  une table de référence ne peut pas contenir de composite ou de repeaters.

La modification d'un contenu de ce type table de référence se fait uniquement dans un tableau.

Une table de référence se déclare en spécifiant le tag « reference-table» (voir plus haut le chapitre sur les tags)

Type de contenu privé

Un type de contenu privé est un type de contenu qui ne peut être créé via les outils standard (menu "Ajouter un contenu" ou lors de la création de page) et qui n'apparait pas dans les moteurs de recherche par défaut.

Les types de contenus ODF (formation, parcours, elp, ...) sont par exemples des types de contenus privés. Ils possède leur propre outils de recherche et de création. L'outil de recherche standard ne permet pas de les rechercher.

Une type privé  se déclare en spécifiant le tag « private» (voir plus haut le chapitre sur les tags)

Type de contenu abstrait

Un type de contenu peut être déclaré « abstrait » avec l’attribut abstract="true"

<cms:content-type abstract="true">
<cms:content-type>

 


Déclaration d'un nouveau type de contenu

Un type de contenu peut-être défini à 2 endroits :

  • dans le répertoire WEB-INF/param/content-types
  • dans un nouveau plugin pour éventuellement mettre en place des traitements plus avancés, comme personnaliser la pipeline de rendu par exemple

Définition dans le répertoire WEB-INF/param/content-types

Dans WEB-INF/param/content-types/[nom_du_plugin] le nouveau type de contenu se définit de la manière suivante :

  • un fichier <id_du_content_type>.xml contient la déclaration du nouveau type de contenu (attributs + vues) comme décrit ci-dessus.

    Exemple de fichier <id_du_contenu>.xml

    <?xml version="1.0" encoding="UTF-8" ?>
    <cms:content-type xmlns:cms="http://www.ametys.org/schema/cms">
        <cms:label i18n="true">application:CONTENT_SEMINAIRE_LABEL</cms:label>
        <cms:description i18n="true">application:CONTENT_SEMINAIRE_DESCRIPTION</cms:description>
        <cms:default-title i18n="true">application:CONTENT_SEMINAIRE_DEFAULT_TITLE</cms:default-title>
        <cms:icons>
            <cms:small>img/seminaire_16.png</cms:small>
            <cms:medium>img/seminaire_32.png</cms:medium>
        </cms:icons>
    
    [...]
    </cms:content-type>
  • l'identifiant réel interne du type de contenu est "content-type.<id_du_content_type>"
  • le répertoire resources/img contient les ressources (notamment les icônes 16x16 et 32x32 pixels du type de contenu)
  • le catalogue i18n par défaut est celui de l'application (dans WEB-INF/i18n)
  • le répertoire stylesheets/content-type.<id_du_content_type> contient l'ensemble des fichiers content-type.<id_du_content_type>.xsl et content-type.<id_du_content_type>-<nom_de_la_vue>.xsl pour le rendu graphique des différentes vues

Le répertoire [nom_du_plugin] peut correspondre à n'importe quel nom de plugins existant. Il est conseillé d'utiliser "web".

Exemple d'organisation de fichiers pour la déclaration d'un nouveau type de contenu "séminaire"

Exemple complet de déclaration d'un contenu simple

Voici ci-dessus l'exemple complet de déclaration d'un nouveau de type de contenu

<?xml version="1.0" encoding="UTF-8" ?>

<cms:content-type
xmlns:cms="http://www.ametys.org/schema/cms">

    <cms:label i18n="true">CONTENT_SIMPLE_LABEL</cms:label>
    <cms:description i18n="true">CONTENT_SIMPLE_DESCRIPTION</cms:description>
    <!-- Les icônes -->
    <cms:icons>
        <cms:small>img/content/simple_16.png</cms:small>
        <cms:medium>img/content/simple_32.png</cms:medium>
        <cms:large>img/content/simple_50.png</cms:large>
    </cms:icons>

    <!-- Liste des attributs -->
    <cms:metadata name="title" type="string">
        <label i18n="true">CONTENT_SIMPLE_TITLE</label>
        <description i18n="true">CONTENT_SIMPLE_TITLE_DESC</description>
        <validation>
            <mandatory />
        </validation>
    </cms:metadata>

    <cms:metadata name="content" type="rich-text">
        <label i18n="true">CONTENT_SIMPLE_CONTENT</label>
        <description i18n="true">CONTENT_SIMPLE_CONTENT_DESC</description>
        <validation>
            <mandatory />
        </validation>
    </cms:metadata>

    <cms:metadata name="seo" type="composite">
        <label i18n="true">CONTENT_SIMPLE_SEO</label>
        <description i18n="true">CONTENT_SIMPLE_SEO_DESC</description>
        <cms:metadata name="keywords" type="string" multiple="true">
            <label i18n="true">CONTENT_SIMPLE_SEO_KEYWORDS</label>
            <description i18n="true">CONTENT_SIMPLE_SEO_KEYWORDS_DESC</description>
        </cms:metadata>
        <cms:metadata name="subject" type="string">
            <label i18n="true">CONTENT_SIMPLE_SEO_SUBJECT</label>
            <description i18n="true">CONTENT_SIMPLE_SEO_SUBJECT_DESC</description>
        </cms:metadata>
        <cms:metadata name="description" type="string">
            <label i18n="true">CONTENT_SIMPLE_SEO_DESCRIPTION</label>
            <description i18n="true">CONTENT_SIMPLE_SEO_DESCRIPTION_DESC</description>
        </cms:metadata>
    </cms:metadata>
    <!-- Fin de la liste des attributs -->

    <!-- Vue d'édition -->
    <cms:metadata-set name="main" type="edition">
        <cms:metadata-ref name="title" />
        <cms:metadata-ref name="content" />
        <cms:metadata-ref name="seo">
            <cms:metadata-ref name="keywords" />
            <cms:metadata-ref name="subject" />
            <cms:metadata-ref name="description" />
        </cms:metadata-ref>
    </cms:metadata-set>

    <!-- Autres vues -->
    <cms:metadata-set name="main" type="view">
        <cms:metadata-ref name="title" />
        <cms:metadata-ref name="content" />
        <cms:metadata-ref name="seo">
            <cms:metadata-ref name="keywords" />
            <cms:metadata-ref name="subject" />
            <cms:metadata-ref name="description" />
        </cms:metadata-ref>
    </cms:metadata-set>

    <cms:metadata-set name="abstract" type="view">
        <cms:metadata-ref name="title" />
    </cms:metadata-set>

    <cms:metadata-set name="link" type="view">
        <cms:metadata-ref name="title" />
    </cms:metadata-set>

    <cms:metadata-set name="index" type="view" internal="true">
        <cms:metadata-ref name="title" />
        <cms:metadata-ref name="content" />
    </cms:metadata-set>

    <cms:metadata-set name="details" type="view" internal="true">
        <cms:metadata-ref name="title" />
    </cms:metadata-set>
</cms:content-type>

 

Définition dans un plugin

Dans un plugin, un nouveau type de contenu est défini dans une extension dans le fichier plugin.xml :

<extension point="org.ametys.cms.contenttype.ContentTypeExtensionPoint"
id="org.ametys.web.default.Content.article"
class="org.ametys.web.contenttype.WebContentType">

    <cms:content-type>
        [...]
    </cms:content-type>
</extension>

Le rendu graphique

Le rendu graphique d'un type de contenu est traité dans la partie Intégration graphique.

Modification d'un type de contenu existant

Il est possible de surcharger un type de contenu existant. Par exemple, pour lui ajouter des attributs et/ou des vues.

Pour surcharger un type de contenu, vous devez créer un fichier <id du content type>.xml dans le répertoire WEB-INF/param/content-types/_override de votre application

Exemple de surcharge des contenus "Actualité" et "Galerie multimédia"

Exemple de surcharge: ajout de l'attribut "subject" et redéfinition de la vue "link"

<?xml version="1.0" encoding="UTF-8" ?>

<cms:content-type xmlns:cms="http://www.ametys.org/schema/cms">
    <cms:metadata name="subject" type="string">
        <label i18n="true">application:CONTENT_NEWS_SUBJECT</label>
        <description i18n="true">application:CONTENT_NEWS_SUBJECT_DESC</description>
    </cms:metadata>

    <cms:metadata-set name="link" type="view">
        <cms:metadata-ref name="title" />
        <cms:metadata-ref name="document-subtitle" />
        <cms:metadata-ref name="start-date" />
        <cms:metadata-ref name="end-date" /> 
        <cms:metadata-ref name="subject" /> 
        <cms:label i18n="true">plugin.web:PLUGINS_WEB_VIEW_ABSTRACT</cms:label>
    </cms:metadata-set>

    <cms:metadata-set name="main" type="edition">
        <cms:metadata-ref name="title" />
        <cms:metadata-ref name="document-subtitle" />
        <cms:metadata-ref name="start-date" />
        <cms:metadata-ref name="end-date" />
        <cms:metadata-ref name="illustration">
            <cms:metadata-ref name="image" />
            <cms:metadata-ref name="alt-text" />
        </cms:metadata-ref>
        <cms:metadata-ref name="subject" />
        <cms:metadata-ref name="abstract" />
        <cms:metadata-ref name="content" />
        <cms:metadata-ref name="comment" />
        <cms:metadata-ref name="contact">
            <cms:metadata-ref name="name" />
            <cms:metadata-ref name="mail" />
        </cms:metadata-ref>
        <cms:dublin-core/>
    </cms:metadata-set>
</cms:content-type>

 

 

 

 

Restriction en lecture ou lecture/écriture

 

<cms:metadata name="typology" type="string">

    <label i18n="false">Typologie</label>

    <description i18n="false">Typologie de projet</description>

    <cms:restrict-to>

        <cms:cannot read-write-direction="write"/>

    </cms:restrict-to>

</cms:metadata>

 

Dans cette configuration, si l'attribut read-write-direction vaut:

  • write : le contributeur peut voir l'attribut, sans pouvoir le modifier (accès en lecture seule)
  • read : le contributeur ne peut ni voir, ni modifier l'attribut
Restriction en lecture ou lecture/écriture en fonction d'un droit

 

<cms:metadata name="typology" type="string">

    <label i18n="false">Typologie</label>

    <description i18n="false">Typologie de projet</description>

    <cms:restrict-to>

        <cms:right id="Web_Right_SuperEdit" read-write-direction="write"/>

    </cms:restrict-to>

</cms:metadata>

 

Dans cette configuration,

  • la balise <right> détermine le droit que doit posséder le contributeur
  • si l'attribut read-write-direction vaut :
    • write : le contributeur ne peut modifier l'attribut que s'il possède le droit "Web_Right_SuperEdit", sinon, il aura accès à l'attribut uniquement en lecture
    • read : le contributeur aura accès en lecture/écriture l'attribut uniquement s'il possède le droit "Web_Right_SuperEdit"

 

Restriction en lecture ou lecture/écriture en fonction d'un état du workflow

 

<cms:metadata name="typology" type="string">

    <label i18n="false">Typologie</label>

    <description i18n="false">Typologie de projet</description>

    <cms:restrict-to>

        <cms:workflow step="2" read-write-direction="write"/>

        <cms:workflow step="3" read-write-direction="read"/>

    </cms:restrict-to>

</cms:metadata>

 

Dans cette configuration,

  • la balise <workflow> détermine l'état de workflow concerné par la restriction
  • si l'attribut read-write-direction vaut :
    • write : le contributeur ne peut modifier l'attribut que si le contenu est actuellement dans l'état de workflow défini
    • read : le contributeur aura accès à l'attribut en lecture/écriture que si le contenu est actuellement dans l'état de workflow défini
Retour en haut