Bonjour,
Dans le cadre du portage de notre site pour l'adapter à l'usage de Spip, nous devons faire face à une difficile décision.
La destination de Spip n'étant pas universelle, nous tombons évidemment sur des besoins que Spip ne prévoit pas. Pour y remédier il y a trois possibilités. Y renoncer, développer en marge de Spip ce qui fait défaut, ou enfin jouer le jeu spip à fond et étendre ses ressources pour lui ajouter ce qui nous manque sous formes de nouveles boucles Spip.
La dernière solution nous semblait la plus élégante. D'abord du point de vue du développement des squelettes, les conventions restaient standard, et les habitudes de programmation acquises sous spip restaient valable. Ensuite parce que l'intégration de nouvelle boucles pouvait éventuellement profiter aussi à la communauté spip.
Un de nos développeurs s'est lancé dans l'aventure avec un certain succès puisqu'il a crée une première version fonctionnelle d'une boucle AGENDA et de la balise formulaire #FORMULAIRE_AGENDA associée. le résultat est encore très basique, mais comme démonstrateur c'est largement suffisant.
Le problème, parce qu'il faut bien qu'il y ait un problème, c'est que ce résultat impose des modifications dans le noyau de Spip. Et cela ne va pas sans quelques craintes justifiées à propos de la compatibilité avec les évolutions de spip qui apparamment s'enchaînent à un rythme assez soutenu. Vu qu'a terme les extentions envisagées risquent de compter une petite dizaine de nouvelles boucles, nous craignons que d'ici quelques mois nous passions l'esssentiel de notre temps à courrir après les nouvelles version de Spip pour les adapter à nos besoins.
C'est un risque que l'on aimerait éliminer, ou tout au moins réduire à une portion la plus congrue possible. Je me demandais si ce type de problème avait déjà été évoqué et s'il avait débouché sur une méthodologie appropriée.
Cordialement.
Jean-Marc Delforge
VTTnet - www.vtt.org
jm.delforge@vtt.org
