Zpip, Composition, Noizetier, Aveline sont tous prévus pour interagir entre eux. Il est vrai que cela est parfois un peu compliqué de voir le rôle de chacun. Par ailleurs, pour Zpip, je distinguerai trois éléments : un mécanisme de génération des pages (qui est en train d’être formalisé sous la forme d’un plugin Zpip-core), une convention de nommage CSS et des contenus par défaut.
#Mécanisme de génération des pages Z
Ce mécanisme est issu de la réflexion décrite par Cédric sur cette page : Modèle de squelette réutilisable.
Grosso modo, chaque page du site est découpé en grands blocs de contenu (en-tête, contenu proprement dit, navigation, extra, pied de page...). D’un côté on définit le gabarit ou layout des pages, c’est-à-dire la manière dont ces blocs sont présentés dans la page, et de l’autre on défini les contenus HTML de la page proprement dit. Ainsi, le contenu d’une page article est défini par le squelette contenu/article.html.
La liste des blocs peut changer d’un site à un autre, le mécanisme étant lui générique. Le mécanisme proposé permet de générer de plus très facilement des pages. En effet, on est pas obligé de définir tous les blocs d’une page, le système pouvant utiliser des blocs par défaut.
Quoiqu’il en soit, on retiendra principalement le découpage des pages en grands blocs, un gabarit se chargeant d’assembler ces différents blocs.
#Zpip-dist et Thèmes Z
Zpip-dist, en plus de ce découpage des pages en blocs, propose en même temps une liste par défaut des blocs (head, entete, pied, contenu, navigation, extra), un contenu pour ces différents blocs et une convention de nommage CSS des éléments HTML des ces contenus. Voir Conventions de nommage dans Zpip et Nommage des classes Z.
Rien n’oblige à utiliser le contenu des blocs définis par Zpip-dist. On peut surcharger cela afin de produire ses propres contenus. Par contre, si on utilise le même découpage de blocs que Zpip-dist et si on utilise les mêmes nommages CSS Z, alors son squelette est compatible avec tous les thèmes pour Zpip. En effet, les thèmes reposent sur un certain découpage en blocs (puisque ce sont les thèmes qui fournissent le gabarit évoqué plus haut) et sur le nommage des classes Z.
On voit bien que l’ensemble de la logique Zpip repose sur trois élements :
- un mécanisme de génération des pages (impliquant une organisation physique particulière des squelettes) qui sera implémenter à terme dans Zpip-core.
- un nommage de classes CSS Z et un découpage spécifique en 6 blocs, utilisés par l’ensemble des thèmes Z
- et enfin des contenus par défaut pour les blocs fournis par le squelette Zpip-dist.
Il est parfaitement possible d’utiliser que certains éléments. Ainsi, SPIP-Contrib utilise le mécanisme de génération des pages Z (Zpip-Core), mais définit sa propre liste de blocs et donc ses propres thèmes.
Je peux faire un site avec mes propres contenus mais respectant les conventions de nommage Z. Dès lors j’utilise le mécanisme de génération des pages Z et les thèmes Z, mais avec des contenus pour les blocs différents de ceux de Zpip-dist.
#Les Compositions
Pour une majorité de sites sous SPIP, on utilise un squelette pour chaque type d’objets. On a donc une page pour les articles, une page pour les rubriques, etc. Plus précisément, on a défini une “mise en page” pour présenter chaque type d’objet. Pour ceux qui travaillent sous OpenOffice, c’est un peu comme les styles de pages. On souhaite parfois une mise en page alternative pour certains objets spécifiques. Ainsi, je vais avoir ma mise en page générique pour les rubriques, mais je veux une mise en page alternative pour la rubrique 12. On cherche donc à faire des variantes.
Cette problématique est ancienne sous SPIP. Un des premiers mécanismes mis en place est celle des variantes de squelettes décrites ici : http://www.spip.net/fr_article3445.html. Le problème de cette approche est qu’il faut connaître à l’avance les identifiants des rubriques, articles, etc. concernés. Et donc ce n’est pas facilement paramétrable via l’espace privé.
Une autre solution qui a été beaucoup utilisée est de sélectionner le squelette d’un objet en fonction d’un mot-clé. Voir par exemple Choix des squelettes par mot clef. Il s’agit d’un détournement de l’usage des mots-clés, introduisant d’un côté des mots-clés sémantiques et de l’autre des mots-clés techniques. Il y a eu de nombreux débats à ce sujet et des pistes d’alternatives explorées puis abandonnées comme Le Plugin Attributs (abandonné).
De là est né le plugin Compositions (merci Cédric) qui permet de sélectionner dans l’espace privé des variantes de mise en page sans avoir à détourner les mots-clés. Les compositions sont dons ces variantes de présentation. Il manque aujourd’hui au plugin compositions la possibilité d’appliquer une variante à toute une branche, par exemple appliquer une composition d’articles à tous les articles d’une rubrique. Plusieurs pistes sont en cours et la discussion revient régulièrement sur SPIP-Zone.
Les mécanismes Z sont parfaitement compatibles avec Compositions. Dans le contexte Z, une composition est donc un contenu alternatif pour les blocs. Surtout, il devient possible de définir une composition en ne modifiant qu’un seul bloc. Ainsi, si je fais un squelette contenu/rubrique-perso.html, je crée une variante/composition (nommée perso) pour les rubriques en fournissant un contenu alternatif pour le bloc contenu (je sais, le mot contenu est ici utilisé dans deux sens différents). Le mécanisme de création des pages Z fait que si on n’a pas spécifié de contenu alternatif pour la composition perso pour les blocs extra et navigation, alors on utilisera les contenu de la page rubrique par défaut.
On retiendra surtout le concept clés des compositions : il s’agit de variantes de présentation.
Dans le contexte Z + Compositions, une page a dès lors un type et une composition. Le type correspond à l’objet visé (rubrique, article...) et compositions est le nom de la composition qui s’applique à cet objet donné (article 12, rubrique 4...), composition étant vide pour la mise en forme par défaut.
#Le noiZetier
Après les gabarits, les blocs et les variantes, le noiZetier introduit le concept de noisettes. Le mots noisettes a été utilisé dans des sens parfois bien différents dans le milieu SPIP. Dans le cadre bien précis du noizetier, une noisette est un morceau de contenu. Le noiZetier permet de sélectionner et de paramétrer les noisettes que l’on souhaite inclure dans chaque page. Les endroits où ces noisettes sont inclues dans la page dépendent du squelette utilisé.
Dans un cadre Z, les noisettes du noiZetier viennent s’ajouter à la fin d’un bloc. Ce sont donc des morceaux de contenus additionnels que l’on ajoute à la fin du contenu défini par le squelette.
Dans l’interface du noiZetier, on indique donc sur quelle page on veut ajouter une noisette et dans quel bloc. On peut ajouter plusieurs noisettes au bloc d’une page, et le noizetier permet bien sur de choisir dans quel ordre. Par ailleurs, les noisettes peuvent recevoir des paramètres et c’est là un de leur grand atout.
Le noiZetier est également compatible avec les compositions. Ainsi on pourra ajouter la noisette A sur la variante V des rubriques, alors qu’on préfère ajouter la noisette B sur la variante W. Ne pas oublier qu’une page c’est type+composition.
En définitive, quand on utilise noiZetier+Zpip, les noisettes sont des morceaux de contenus que l’on ajoute à la fin des blocs d’une page.
#Aveline
Le projet Aveline pousse le mécanisme du noiZetier au point que tous les contenus des blocs sont définis sous formes de noisettes, le tout étant défini et paramétré dans l’interface privé.
Aveline utilise le mécanisme Z et la convention de nommage Z afin d’être compatible avec les thèmes pour Z.
Autrement dit, dans le contexte d’Aveline, une page a un gabarit et un design CSS défini par le thème, elle est découpée en blocs (contenu, extra et navigation + en-tête et pied de page) et le contenu des blocs est composé de noisettes.
Aveline est compatible avec les compositions, celles-ci restant toujours la même chose : des variantes de présentation. Et avec Aveline, une composition est donc simplement une autre liste de noisettes. Mais, dans la mesure où le contenu des pages est géré via l’interface privée, il devient possible de créer des compositions directement depuis l’interface privé. Ce que j’ai appelé les compositions du noiZetier (voir Les compositions du noiZetier) qui prennent tout leur sens dans le cadre d’Aveline.
Pour l’utilisateur, c’est toujours la même chose : des variantes de présentation. La différence n’est que technique au sens où ces compositions sont définies en base de données et non sous formes de squelettes HTML.