Accueil > SPIP > À propos de Zpip, de Compositions, du noiZetier et d’Aveline

À propos de Zpip, de Compositions, du noiZetier et d’Aveline

vendredi 26 novembre 2010
Mis à jour le samedi 12 février 2011

Reprise ici d’une réponse écrite dans un forum de SPIP-Contrib.

Ce texte est largement améliorable. Ne pas hésiter à faire des commentaires.

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.

Commentaires

  • Le 11 octobre 2012 à 13:23, par ?

    Bonjour Joseph,
    j’utilise l’ensemble de tes plugins, (à part Aveline) c’est très chouette.
    Est-ce qu’il existe une alternative à un bloc qui n’a pas été rempli par des noisettes ? Un appel sur un fichier par défaut ?
    Merci à toi

  • Le 9 juillet 2011 à 12:01, par klelugi

    Bonjour,

    Je suis en train de découvrir Aveline, un très très gros boulot et de très bonne idées, bravo !

    Aujourd’hui, via l’admin on peut gérer les variables de chaque noisette et cela concerne le HTML avant tout.
    Parfois pour le CSS, des champs sont disponibles pour ajouter une classe et dans la noisette Anything Slider par exemple, le JS est géré dans le HTML de la noisette elle-même.

    Est-il envisageable, prévu ou simple à mettre en oeuvre de créer une gestion aussi bien du HTML comme c’est déjà le cas que des CSS et JS,

    Lors de la création d’une page on aurait alors,

    • la page HTML : gabarit/composition incluant les diverses portions de page avec chacune leurs noisettes respectives
    • la feuille de style « dynamique », qui en fonction de l’ordre des portions de page (contenu, extra, navigation,...) et de l’ordre des noisettes serait générée grâce à des formulaires génériques du même type que chaque fichier HTML par noisette
    • et le fichier JS qui de même recollerai les différents besoins de chaque noisette et cela dans l’ordre d’apparition des noisettes aussi

    On pourrait alors imaginer qu’une noisette serait représentée par 4 fichiers : le yaml pour la configuration, le HTML pour le gabarit puis le fichier.css.html pour la CSS et le fichier.js.html pour le JS

    Ainsi chaque bloc serait aussi configurable via l’admin aussi bien pour son contenu que pour sa présentation (CSS/JS)

    • Le 12 juillet 2011 à 15:07, par Joseph LARMARANGE

      Il me semble important de ne pas trop compliqué le noiZetier sinon cela risque de devenir une véritable usine à gaz qui sera difficilement maintenable.

      Concernant la mise en forme, le choix réalisé pour Aveline est, volontairement, de suivre la nomenclature Z et donc d’être compatible avec les thèmes Z. Autrement dit, la mise en forme est gérée séparément, via les thèmes. Il faut que l’on puisse changer de thème sans problème.

      Rien n’interdit de développer un thème configurable. Mais cela sera du ressort du thème et non des noisettes.

      Après, mettre en place une gestion de styles noisette par noisette avec reconstruction d’une feuille de style par page me semble complexe à mettre en oeuvre mais surtout complexe à configurer ensuite pour l’utilisateur avec un risque d’incohérence de la mise en forme sur le site produit.

      Après, rien n’interdit de développer une collection de noisettes personnelles avec des choix de styles proposés à l’utilisateur, avec un ou plusieurs thèmes fournissant les styles correspondant. Mais on sortirai alors de la compatibilité avec les thèmes Z.

      Bref, la question n’est pas triviale et je ne vois pas de réponse simple à fournir dans l’immédiat. Il faudrait creuser plus les implications.

      Cordialement

    • Le 17 juillet 2011 à 11:09, par klelugi

      Merci Joseph pour cette réponse,

      Effectivement, la mise en place de la gestion « aveline + noizetier + zpip » est déjà relativement compliquée, la gestion graphique par des thèmes semble alors plus simple et ouverte aux propositions des contributeurs.

      En tout cas, très belle contrib et vraiment très pratique, encore bravo !

      Répondre à ce message

  • Le 3 février 2011 à 11:52, par Loiseau2nuit

    Yeha ! T’assures ! Un gros « Merci » :-D

    Répondre à ce message

  • Le 2 février 2011 à 13:39, par Loiseau2nuit

    Hello :-)

    Ce plugin et ce concept de squelettes sont absolument géniaux. J’ai toujours pensé que l’avenir de la création web résidait dans un concept « puzzle » et le noiZetier en est la représentation parfaite, ya rien à redire là dessus :-)

    En revanche, je me permet de reprendre ici (tant qu’à faire) une suggestion qu’on a brièvement abordé sur IRC et pour laquelle je ne suis pas sûr d’avoir été très clair : la possibilité d’ajouter des class CSS aux noisettes que l’on créé.

    L’idée n’est pas de sortir du formalisme ou de la nomenclature définie par les squelettes Z, bien au contraire même, mais juste de pouvoir surcharger les class existantes avec des class perso définies dans les feuilles perso.css des thèmes.

    En quelque sorte le but est d’étendre, sans péter toute compatibilité, le principe d’attribution de class css déjà en place dans le plugin.

    Exemple : Je créé une noisette de type bloc texte, celle-ci se retrouve automatiquement affublée d’une class .noisette + .noisette_bloc_texte

    Là, un champ supplémentaire sur les formulaires de configuration des noisettes pourrait alors permettre d’ajouter une class en plus sans remettre en cause les première. Il est même important que les premières restent pour garder les fondements de la mise en forme justement ! Les class persos introduirait alors des variations propres au design que veut mettre le webmaster en place.

    <div class="noisette noisette_bloc_texte fond_rouge">blah blah</div>

    ou

    <div class="noisette noisette_bloc_texte bordure_verte">blah blah</div>

    par exemple.

    Alors oui bien sûr c’est un paramètre que l’on peut introduire soi même dans une noisette au besoin, comme tu me le disais mais je pense que l’ensemble du plugin aurait beaucoup à gagner si le mécanisme était généralisé, comme il l’est pour le plugin « Menus » par exemple, où tu peux ajouter des class sur ce principe, aussi bien au conteneur du lien de menu, qu’au lien lui même, permettant d’ajouter des subtilités de design aux styles de base déjà définis par habillage.css.

    Je ne sais pas vraiment ce que ca impliquerait en terme de dev mais ca apporterait un réel « plus » je pense.

    My 2 Cents :-)

    • Le 2 février 2011 à 15:28, par Joseph LARMARANGE

      La question qui se pose est de savoir s’il faut rajouter cette possibilité noisette par noisette ou bien si ça doit être une option générique pour TOUTES les noisettes, directement gérée par le noiZetier dans ce cas.

      Je n’ai pas d’avis tranché là-dessus pour le moment.

    • Le 2 février 2011 à 15:35, par Joseph LARMARANGE

      Effectivement,

      le plugin Menus stocke ça directement en base de données pour chaque menu.

      Ensuite, pour chaque entrée de menu, c’est géré par l’entrée de menu elle-même.

    • Le 2 février 2011 à 22:09, par Joseph LARMARANGE

      Zou, réglé avec la version 0.9.5 du noiZetier. Voir http://zone.spip.org/trac/spip-zone...

      Amicalement

      Répondre à ce message

Répondre à cet article

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Retour haut de page
Site réalisé avec SPIP | Plan du site | Contact | Crédits | Mentions Légales | Suivre la vie du site RSS 2.0
Habillage visuel © Larma par Joseph Larmarange sous Licence Creative Commons Attribution 2.5 License