ZCM - Squelette modulaire SPIP/ZCore

/ZCM-Squelette-modulaire-SPIP-ZCore.html

  • #Intégration / #développement : Plugin vs #boiler_plate

    Vous êtes plutôt l’un ou plutôt l’autre vous ?

    Il y a 1 an, j’attaquais mon squelette perso, celui qui me sert aujourd’hui de base pour la structure html et quelques styles css de bases et qui repose sur ZPIP V2. Ce squelette est (plus que) largement inspiré de Intégraal de @rastapopoulos et SPIPr de Cédric et @ben.

    Je commence à avoir quelque chose d’assez adapté à mes besoins. Outre une structure html5, ça permet de gagner beaucoup de temps : une grille à mettre en place ? <INCLURE{fond=inclure/liste/grille,...> + les bons paramètres et le tour est joué.

    La question qui se pose maintenant, c’est le fonctionnement : boilerplate ou plugin.

    Le plugin , c’est un squelette qu’on surcharge avec un squelette/plugin propre à chaque nouveau projet. Le boilerplate , c’est un squelette qu’on modifie directement pour chaque nouveau projet.

    L’avantage du 1er, c’est qu’on partage les évolutions entre tous les sites qui l’utilisent mais l’inconvénient, c’est qu’il faut conserver une compatibilité descendante sous peine, soit de casser le site, soit de ne plus pouvoir profiter des évolutions.
    Le 2nd, ben c’est exactement l’inverse.

    Au début, le fonctionnement plugin m’allait très bien : je développais mon plugin en même temps que les sites et chacun profitait donc des mise à jour de la structure et des styles de bases. Mais à force de bouger des choses, je me rends compte que ça devient galère de garder cette compatibilité descendante.

    Donc voilà, si vous avez des retours d’expérience...

    Liens :
    SPIPr : https://zone.spip.net/trac/spip-zone/browser/spip-zone/_squelettes_/spipr-dist/trunk
    Integraal : https://zone.spip.net/trac/spip-zone/browser/spip-zone/_squelettes_/integraal
    integraal (principe) : https://zone.spip.net/trac/spip-zone/changeset/83559/spip-zone
    Repo de mon plugin : https://gitlab.com/jmoupah/zcm
    Doc de mon plugin : https://notes.cousumain.info/ZCM-Squelette-modulaire-SPIP-ZCore.html

    #SPIP_recette #SPIP

    • Les deux, cela dépend du type de projets sur lesquels tu travailles.

      C’est l’exact raison pour laquelle j’ai conçu Intégraal, parce que Zpip ou SpipR ne convenait pas du tout dans les cas où on avait des clients différents, avec des graphismes dédiés à chaque fois, où il faut intégrer des maquettes précises, qui n’ont rien à voir les unes avec les autres.

      Dans ce cas, l’avantage d’avoir un plugin commun se réduit drastiquement, pour deux raisons :
      1) tu finis par surcharger au moins 50% du truc de base
      2) quand il y a une mise à jour du plugin central, ça peut très souvent te péter ton intégration, puisque tu avais basé du graphisme sur une structure qui peut bouger à tout moment !

      Voilà donc pourquoi cela fait des années que l’on travaille avec Intégraal et désormais sa commande spip-cli qui permet en 2s d’avoir la structure d’intégration, qu’ensuite on modifie directement.

      En revanche, attention, si une partie du travail concerne tout un ensemble de clients qui se ressemblent au moins un peu, et aussi si tu arrives à avoir des bases génériques ET configurables (noisettes ou autre), alors dans ce cas là ça peut de nouveau être intéressant d’avoir un plugin-squelette qui est le même pour tout le monde, et sur lequel tu ne fais que plaquer des styles (et pour ça il faut que tes classes CSS soient génériques aussi, quand je parle de générique, c’est pas juste au niveau des squelettes, <inclure>, etc).

      Actuellement, en plus de continuer à utiliser Intégraal, nous sommes en train de réfléchir à un plugin commun aussi, pour d’autres besoins.

      En simplifiant :

      Intégraal = site à façon, où on conçoit un ensemble de fonctionnalités, une ergonomie et un graphisme propre à ce site, puis on l’intègre tel qu’on l’a conçu.

      Plugin = site où on propose aux gens des fonctionnalités qui sont déjà à moitié intégré, parce que ça rentre vraiment dans le périmètre de leurs besoins, et sur lesquels on change juste quelques petites différences graphiques (palette de couleur, typo, header, etc).

    • Mais du coup, si on change son boiler plate en plugin spécifique au nouveau projet, ça veut dire que chaque nouvelle fonctionnalité ajoutée en cours de développement (donc dans le nouveau projet, tout le monde suit ?) doit être reportée dans le boiler plate source pour profiter au prochain projet.

      Ça veut peut être dire qu’il faut attendre que le boiler plate soit arrivé à maturité avant de fonctionner comme ça...

      bon, work in progress quoi...

    • Bah oui, mais seulement si c’est une fonctionnalité générique. Le principe du boiler plate c’est qu’ensuite tu modifies en fonction de ton projet précis. Mais à tout moment, et surtout au début bien sûr, tu peux détecter que tel ajout va te servir dans d’autres futurs projets, donc tu l’ajoutes à ton projet en cours, tu le testes, tu trouves ça cool, et alors tu le reportes sur le boiler plate. C’est ce qu’on fait dans Intégraal depuis le début (même si on n’est pas forcément très rigoureux, ya sûrement plein de choses encore à reporter).

    • Hello,

      après expérience, je suis resté sur le fonctionnement boiler plate. Même s’il impose une rigueur pour reporter les nouvelles fonctionnalités développées au fur est à mesure, c’est toujours plus réaliste que de vouloir garder une rétro-compatibilité en mode plugin.

      Voilà pour mon retour d’expérience perso...

      Merci aux uns et aux autres pour les retours, pistes, outils.

    • Oui c’est bien là l’argument principal : la pérennité et la maintenance sur le long terme. Quand t’as utilisé ce projet pour un site, après 3 ans, ça se trouve tu ne veux plus utiliser la même grille SCSS, t’as améliorer la sémantique du HTML ou la normalisation des classes CSS (BEM etc), bref t’as fait plein de changement, et donc tes personnalisations de l’époque peuvent être toutes pétées si ton projet était un plugin générique à mettre à jour.

      Alors qu’avec un boiler plate, tu l’as utilisé tel qu’il était au moment où tu en avais besoin, et tu l’as personnalisé, et basta. Si 3 ans plus tard ya une refonte à faire, de toute façon ça sera sur une autre base. Et si c’est juste des petites modifs, c’est sur le socle de l’époque.

      Bien sûr ça c’est quand on doit intégrer des maquettes précises. Quand on propose une solution générique et que les clients ne font que choisir parmi des trucs existants, là faut tout en plugins.

  • Je viens de mettre en ligne le site de Bord à Bord, Recettes de cuisine et produits aux algues bio de Bretagne https://www.bord-a-bord.fr.

    Pour ce site, j’ai eu pas mal recours à la communauté #SPIP (assez présente ici) via les docs et les listes et je me dis qu’un petit retour d’expérience (à la manière de ceux d’@arno que je lis toujours avec intérêt) serait le bienvenu. Ne le voyez donc surtout pas comme un autopromo déguisée.

    Et bien sûr, tout retour est bienvenu.

    Graphisme

    Toute la partie graphique, conception et identité visuel, a été crée par Oui design - bureau de design graphique, je suis uniquement intervenu sur des questions d’ergonomie ou de faisabilité technique.

    Principe

    Comme les produits ne sont pas en vente directe mais via des magasins, l’idée du site a été de mettre l’accent sur la présentation des algues et de fournir des recettes avec ces produits pour que les gens sachent quoi faire avec.

    Et on navigue à travers tout ça de façon horizontale : dans une recette on retrouve les liens vers les produits utilisés ainsi que vers les algues qu’ils contiennent. Depuis une page algue, on accède aux produits qu’elle compose et aux recettes faites avec, etc... Ces liens fonctionnent avec des mot-clefs.

    Donc 3 parties principales :
    – histoires d’algues
    – Les recettes du bord
    – les produits

    Et à côté :
    – les points de ventes
    – la présentation

    Histoires d’algues : le choix esthétique à été de faire une page à défiler (type « one page »).
    https://www.bord-a-bord.fr/-Histoires-d-algues-.html

    Un menu en haut de page permet de voir ce que la page contient et d’y accéder en scrollTo avec le plugin Ancres douces. La structure de la page est donc une rubrique affichant tous ses articles sur un même page.

    Recettes : la page affiche par défaut les dernières recettes.
    https://www.bord-a-bord.fr/-Les-recettes-du-bord-.html

    En haut de page, on retrouve le diaporama permettant de mettre en avant certaines recettes (en fonction des saisons, des nouveaux produits...) puis un champs de recherche et 3 possibilités de filtre (par produit, ingrédient ou temps de cuisson).

    Ces filtres sont des <select> de mot-clefs gérés avec Chosen. Comme tous les mots clefs ne sont pour l’instant pas utilisés, j’ai fait une jointure mot-clefs et articles de la rubrique recette pour n’afficher que les mots clefs effectivement ajoutés à des recettes et ne pas avoir de résultat vide.

    Chaque recette a des Champs extras pour les durées de préparation.

    Pour gérer l’affichage du visuel dans la grille de la page rubrique (toutes les recettes) et sur la page article (une recette), j’ai utilisé Rôles de documents : visuel grille + visuel présentation.
    Une difficulté pour moi a été de créer les rôles via mon plugin squelette (merci à @rastapopoulos et Tcharlss pour le SAD sur le forum du plugin).

    Il y a aussi des recettes similaires, pour favoriser la circulation entre les recettes, avec A2A permettant de lier des articles entre eux.

    Les produits : une page rubrique affichant tous les articles rangés en sous-rubriques pour pouvoir gérer les gammes de produits (Gamme Fraîche > Les tartares > Le Classique).
    https://www.bord-a-bord.fr/-Les-produits-.html

    Une des questions ici a été la structure HTML5 : qu’est-ce qui est <section> et <article>. Le choix a été de faire un article par type de produit (tartares, moutardes...) avec les différents produits (le classique, le provençal...) en <nav>.

    Ici aussi les différents visuels fonctionnent avec Rôles de documents et des champs extras permettent d’afficher le conditionnement du produit. On retrouve également un diaporama Slick en entête pour mettre en avant certains produits.

    Points de vente : on affiche avec GIS une carte avec clustering des points et possibilité de se géolocaliser.
    https://www.bord-a-bord.fr/-Points-de-vente-.html

    La difficulté a été ici de trouver un fonctionnement permettant au client de mettre à jour facilement les points de vente à partir de son doc tableur source. Je détaille la démarche par ici https://contrib.spip.net/Tutoriel-Afficher-sur-une-carte-GIS-des-points-dont-on (poke @b_b :) )

    Les autres principaux plugins utilisés :
    – Multilang + Menu de langues avec liens : le site est prévu pour être multilingue mais la traduction est en cours
    – Big upload pour facilité l’ajout des documents par drag and drop
    – centre image pour définir le centre d’intérêt des images et recadrer en fonction
    – court-circuit pour afficher directement l’article d’une rubrique s’il est seul
    – favicon pour gérer les favicons en fonction des appareils
    – Image responsive et Insertion avancée d’images pour gérer les images en fonction des types d’affichage (HD ou pas) et des tailles d’écran le tout en HTML5 (<picture>)
    – Manuel de rédaction du site pour laisser un mode d’emploi détaillé aux utilisateurs
    – Métas+ pour les méta-données openGraph et DublinCore pour un meilleur affichage sur les réseaux sociaux
    – Responsive Nav pour le menu burger sur petits écrans
    – ZCore
    – ZCM, mon plugin squelette perso pour ZCore que je vais tenter de documenter au fur et à mesure par ici https://notes.cousumain.info/ZCM-Squelette-modulaire-SPIP-ZCore.html

    Certains « détails » auxquels il a fallu penser :
    – ne pas afficher dans le sitemap et le plan du site les articles et rubriques n’ayant pas vocation à être vu tels quels
    – backend : n’afficher que les recettes

    J’ai également commencé à utiliser les svg pour ce site, mais ce n’était que le début, donc certains pictos sont en svg, d’autres non.

    Voilà pour mon retour d’expérience, je me dis que ça serait une chouette ressource si d’autres dev faisait de même. On pourrait même trouver un hashtag :)