Ces 2 bouts de code n'implémentent rien moins que des systèmes de squelettes orthogonaux à celui proposé par le noyau de SPIP.
Je suis assez ébahi de ce genre de développement qui de mon point de vue vont à l'encontre du développement collaboratif:
Je suis assez étonné de cette remarque.
CFG du temps où Toggg était là a fait l'objet de nombreuses discussions toutes publiques. Mettre cette fonctionnalité en plugin était un moyen de tester grandeur nature les propositions et améliorer l'outil dans la réalisation des différents besoins exprimés. Dire que ce n'était pas un développement collaboratif, c'est nier tout ce travail et cette expérience accumulée. Le pourquoi CFG a été réalisé et est maintenu est toujours valable.
le système de squelette officiel de SPIP a beaucoup d'atouts, quand on tombe sur une limitation il faut essayer de l'améliorer plutôt que de faire un système orthogonal dans son coin, qui aura au moins autant de lacunes que celui développé en commun à l'origine, même si ce ne sont pas les mêmes.
Lorsque qu'un besoin éclot, des solutions émergent et la plus pratique à cette instant devient la référence, avec ou sans l'accord du «core» de SPIP.
Il y a des tas d'évolutions possibles pour le Core, si on s'amuse à brider tous les développeurs sous le prétexte qu'on jour, SPIP, nativement aura une API propre pour telle ou telle chose, tout le monde partira : cela fait des années que certaines choses sont demandées et ne sont pas là. Que faire ? Il est évident que certaines solutions provisoires vont durer encore longtemps.
Dire que CFG ou prive/exec/x.html est une surcharge de la syntaxe de SPIP, ce n'est évidemment pas faux. Mais intégrer cela ou intégrer des fichiers .xml ou .yaml mitoyens c'est exactement pareil : c'est aussi en quelque sorte augmenter la syntaxe de SPIP d'une autre manière.
En pratique, pour la prochaine version de SPIP, savoir une 2.2 qu'il faudrait vite sortir pour rapidement mettre un terme à ces dérives,
Cette haute autorité aurait un peu tendance à me chagriner. Il y a toujours le code théorique, et l'utilisation réelle des gens.
Changer d'un coup l'API de spip_meta pour intégrer la solution que tu as pensé pour «Association 2» en demandant de sortir rapidement une version 2.1.1, est-ce du développement collaboratif ? Je me pose des questions alors même qu'il y avait eu ce genre de même réflexions sur CFG en son temps et que faute de consensus et de volonté, tout était resté en stand by.
Je note quelques remarques tout de même au passage sur ce que tu proposes pour Associations :
- Une table spip_meta_$prefixe par plugin est abérant dans 95% des situations de configurations ou on a guère plus que 10 valeurs à configurer. Tout stocker dans spip_meta en vrac ne me convient pas plus. Je trouvais la sérialisation de CFG assez agréable justement en n'ajoutant qu'une entrée par plugin dans spip_meta.
- Un simple file_get_contents() sur la source d'un formulaire capable d'analyser les saisies est tout aussi impossible. Trois exemples :
1) #INCLURE{fond=inc/morceau_de_formulaire}
2) <input type="text" name="#ENV{name}" value="#ENV{value}" /> et
3) <BOUCLEx(RUBRIQUES){racine}><input type="text" name="secteur#ID_SECTEUR" value="#ENV{secteur#ID_SECTEUR}" /></BOUCLEx(RUBRIQUES){racine}>.
Ces trois situations sont impossibles à calculer sans un premier recuperer_fond() sur la source.
Cela est tout aussi vrai si c'est un fichier .xml ou .yaml qui indique quelles sont les saisies à prendre : des saisies qui dépendent d'une boucle ne peuvent difficilement être connues.
Il y a de nombreuses situations de configuration qui vont à un moment se percuter si une API est proposée par le core et comme cela a été pour CFG. Si on veut que ça tienne la route, il y a des choix à faire. Mais dire que remplacer CFG (je ne suis en rien contre, je précise) du jour au lendemain est aussi simple que cela est totalement une illusion à mon avis.
Donc... avant de se presser sur une 2.2 qui corrigerait tout d'un coup par miracle... il est urgent de prendre le temps d'y aller à petit pas, de se poser les bonnes questions et d'être attentif à ce qu'attendent les bidouilleurs du dimanche.
J'apprécie ce regard neuf sur les plugins et leur code, c'est une très bonne chose que tu les découvres tout juste et apportes de nouvelles idées. Mais please, ne casse pas tout sur un coup de tête ^^
