[spip-dev] Utiliser des tableaux dans les squelettes SPIP

Dev
1

Je propose ici d'arrêter de troller à droite à gauche (liste privée, IRC, etc) afin que tout le monde puisse participer et communier ensemble.

Rappel.
Cédric a récemment (je crois) introduit des modifications majeures permettant de boucler sur pas mal d'autres choses que des tables. Et notamment sur n'importe quel tableau (php, #ARRAY, etc).
Mais ça ne plaît pas à tout le monde et pour l'instant ça a été retiré.

Il y a un sondage qui permet de jouer à "qui c'est qui a le plus d'amis" :
http://www.doodle.ch/participation.html?pollId=qwx5r924npxvz6it

Maintenant, j'aimerais donner mon avis.
Les connecteurs permettent de faire beaucoup de choses autre que manipuler les tableaux, mais pour ces choses, je pense qu'il est bien qu'on puisse se brancher dessus et que des plugins puissent rajouter des connecteurs. (Ce qui peut se discuter pour des trucs de base comme les conditions, mais c'est un autre débat pour l'instant.)

En revanche, en ce qui concerne les tableaux, je maintiens (et ce, au moins depuis qu'on a discuté de #FOREACH) que le code DOIT absolument être dans le core.

En effet, depuis un certain temps déjà SPIP permet de manipuler les tableaux. On peut les créer avec #SET et #ARRAY, on peut ajouter et sortir des éléments avec des filtres. Mais à aucun moment on ne peut lister de manière exhaustive et explicite l'ensemble (ou une partie choisie) des éléments d'un tableau.
On peut évidemment utiliser les fonctions de tableaux dans des boucles SPIP, mais c'est tout. Si l'on construit un tableau dont le nombre d'éléments n'est pas en rapport avec une table de SPIP, on n'a aucun moyen de boucler dessus.

En l'état, c'est donc à mon sens *totalement illogique* ! On a qu'une moitié de fonctions permettant de manipuler les tableaux. L'autre devant désormais se retrouver en plugin suite aux modifs de Cédric.

Soit les développeurs mettent tout ce qui concerne les tableaux dans un plugin (ce qui paraît ridicule non ?), soit tout dans le core. Mais pas moitié-moitié. Question de cohérence.

Voilà mon avis.

2

La vraie alternative du jour est la suivante:

1 la communauté SPIP est elle encore capable de sortir une version stable après 18 mois de silence qui en inquiètent plus d'un,
2 ou bien SPIP n'est-il qu'un amas de codes informe évoluant dans tous les sens, au gré des pressions d'utilisateurs consuméristes inconscients des implications de leurs demandes.

Si la réponse est la 2, continuez sans moi.

esj

3

ben y a une version prete a faire la beta sur le repository, hors le plongeur qui prend pas racine et les formulaires tous cassés dans IE, donc je vois pas mort d'homme là...

4

1 la communauté SPIP est elle encore capable de sortir une version stable

Il reste * 1 * bug, donc je pense qu'on va y arriver. Ca n'interdit
pas de discuter.

après 18 mois de silence qui en inquiètent plus d'un,

10000 commits c'est du silence ?

PS: Alerte météo sur la France : le temps est à l'orage

-- Fil

5

Committo,Ergo:sum a écrit :

La vraie alternative du jour est la suivante:

Il y a, je pense, un juste milieu entre être sommé, obligé, torturé s'il le faut, de faire tout ce que les utilisateurs veulent-absolument-parce-que-c'est-trop-pratique, et développer tout seul dans son coin, ou presque, parce que nous-on-sait.
On peut aussi discuter sur tel ou tel point.

Par exemple, que ça ne soit pas pour SPIP 2 ne pose pas spécialement de problème. Ai-je parlé d'un quelconque numéro de version dans mon précédent message expliquant la chose ?

L'argument le plus pertinent, c'est que pour SPIP 2, il a été dit que, changement de version oblige, la syntaxe devait être pérenne. Or pour les nouveautés introduites par Cédric, les syntaxes n'ont justement pas encore été testées/discutées/etc. Donc ça paraît logique ça ne soit pas intégré immédiatement.

Il est par exemple possible de brancher un plugin sur les ouvertures que Cédric a laissé, et que, plus tard, après tests et discussions, certaines parties puissent intégrer le core.

Mais bon. C'est tout hein.