jeanmarie

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).

Oui, c’est reporter les évolutions qui semble contraignant.

Je vais tester ce fonctionnement pour mon prochain projet.

A suivre donc...

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.