[spip-dev] Changement de structure des formulaires

Dev
1

Salut Cédric,

J'ai comme un doute sur la modification suivante :

On vient de sortir une version bêta, cela laisse penser que la release de SPIP 3.1 est proche.

D'après ce que j'ai lu, la compatibilité est assurée pour les formulaires qui utilisent l'ancienne structure à base de ul/li, à condition d'ajouter la classe "editer-groupe" sur les ul.

(l'impact visuel sans cette classe ne semble pas énorme à première vue)

Pour les formulaires qui utilisent saisies, il faut les modifier pour utiliser [(#VAL{ul}|saisie_balise_structure_formulaire)] class="editer-groupe" à la place de ul :

Sans ça, les formulaires génèrent une structure ul/div pas "très classe".

En résumé, il faut modifier le code des formulaires dans les deux cas. Du coup, certains plugins qui sont marqués comme compatible SPIP 3.1, ne le sont plus vraiment.

/me en train de se rendre compte de la chose

http://ljdchost.com/slkNhno.gif

Malgré tout ça, je pense qu'il est trop tard pour revenir en arrière vu le nombre de modifications que cela a entraîné. On aurait dû réagir plus tôt, tant pis... Et puis, peut-être qu'on en discutera avant la prochaine fois :slight_smile:

Que peut-on faire pour améliorer la situation ?

- j'ai souvenir d'une discussion sur IRC pour utiliser une syntaxe un peu plus sympa pour les formulaires qui utilisent saisies (#DIV de mémoire).
- à voir si on peut limiter l'impact visuel pour les formulaires qui n'utilisent pas saisies

D'autres avis/idées ?

2

C’est bien l’intérêt des phases beta de tester de nouvelles fonctionnalités qui apportent certaines incompatibilités.

Perso je pense qu’il faut garder les nouveaux formulaires.

Que cette modification importante soit intégrée à la 3.1, ce n’est plus ce qui compte maintenant : la modification est intégrée au core depuis plus d’un mois, et le mouvement de certains plugins a suivi - et donc que c’est aux plugins qui les utilisent de s’adapter
Plus de choix maintenant, on a parfaitement appliqué la méthode du “go go go, on discute après” – spéciale dédicace pour km :))

bises,

.Gilles

3

C'est bien l'intérêt des phases beta de tester de nouvelles
fonctionnalités qui apportent certaines incompatibilités.

Si on doit introduire des incompatibilités, c'est avant la phase béta.
Une version béta c'est une pré release, sur laquelle on peut corriger des bugs, mais pas changer une API ou une structure de code.

Perso je pense qu'il faut garder les nouveaux formulaires.

Que tu penses qu'il faille les garder ou pas n'a aucune importance de toute façon, la décision a déjà été prise, sans aucune annonce ni discussion.
Et la doc officielle a déjà été modifiée :

Que cette modification importante soit intégrée à la 3.1, ce n'est plus
ce qui compte maintenant : la modification est intégrée au core depuis
plus d'un mois, et le mouvement de certains plugins a suivi - et donc
que c'est aux plugins qui les utilisent de s'adapter

C'est donc un décision verticale (c'est aux plugins de s'adapter), qui a été prise (je le répète) sans discussion.

Et sans annonce non plus : ce serait donc à tous les développeurs de plugins de suivre les logs de commits ? et de lire le code pour se rendre compte qu'ils sont censés repasser sur tous leurs formulaires ? (sans doc de migration non plus)

"nul n'est censé ignorer la loi", ouais, c'est à peu près aussi con.

Plus de choix maintenant, on a parfaitement appliqué la méthode du "go
go go, on discute après" -- spéciale dédicace pour km :))

C'est pas une méthode ça.
Trop facile de pousser son code sans communiquer.
C'est ça un projet libre ? chacun fait ce qu'il veut et c'est le plus fort qui gagne ? ou le dernier qui a parlé qui a raison ?

Il reste quoi à discuter, "après" ?

4

C'est bien l'intérêt des phases beta de tester de nouvelles
fonctionnalités qui apportent certaines incompatibilités.

Si on doit introduire des incompatibilités, c'est avant la phase béta.
Une version béta c'est une pré release, sur laquelle on peut corriger des
bugs, mais pas changer une API ou une structure de code.

Mais pour SPIP il n'y a pas de différence entre la branche "beta" et la
branche "développement".
Comment fait-on actuellement pour préparer une version 3.2 ?
On ne peut rien faire tant que la branche 3.1 n'existe pas dans le dépôt
svn.

Je propose donc, pour que d'autres incompatibilités surviennent, qu'une
branche 3.1 soit créée, et que le trunk devienne une 3.2-dev

C'est donc un décision verticale (c'est aux plugins de s'adapter), qui a
été prise (je le répète) sans discussion.

Oui certes, mais le développement de SPIP se fait souvent de cette façon.
Ce qui ne veut pas dire que ce soit la meilleure méthode non plus

Et sans annonce non plus : ce serait donc à tous les développeurs de

plugins de suivre les logs de commits ? et de lire le code pour se rendre
compte qu'ils sont censés repasser sur tous leurs formulaires ? (sans doc
de migration non plus)

Je crois que Cédric a envoyé un message sur la liste spip-zone pour
informer du changement sur la structure des formulaires.
C'était le 13 juin, et ça a entrainé une discussion avec Ben, Jacques et
Rastapoulos

Plus de choix maintenant, on a parfaitement appliqué la méthode du "go

go go, on discute après" -- spéciale dédicace pour km :))

C'est pas une méthode ça.

C'en est une parmi d'autres.
Si elle avait été appliquée pour le logo, on aurait déjà un nouveau logo :wink:

Trop facile de pousser son code sans communiquer.

Je ne suis pas d'accord : les commits sont super bien détaillés pour SPIP.
J'ai moi-même communiqué sur ce changement par Twitter :

C'est ça un projet libre ? chacun fait ce qu'il veut et c'est le plus fort
qui gagne ? ou le dernier qui a parlé qui a raison ?

Oui c'est plus libre justement : le "go go go et on discute après" permet
de créer sans se poser trop d'apriori -
Certes, ce n'est pas une gestion de projet web classique avec une deadline,
des features annoncées pour les prochaines versions, des batteries de tests
avant validation, etc..

Il reste quoi à discuter, "après" ?

Après plus d'un mois, effectivement, plus grand chose.

5

Gilles Vincent a écrit le 15/07/2015 00:42 :

Je crois que Cédric a envoyé un message sur la liste spip-zone pour
informer du changement sur la structure des formulaires.
C'était le 13 juin, et ça a entrainé une discussion avec Ben, Jacques et
Rastapoulos

Ici : http://thread.gmane.org/gmane.comp.web.spip.zone/38101

6

Gilles Vincent a écrit le 15/07/2015 00:42 :

Je crois que Cédric a envoyé un message sur la liste spip-zone pour
informer du changement sur la structure des formulaires.
C'était le 13 juin, et ça a entrainé une discussion avec Ben, Jacques et
Rastapoulos

Ici : http://thread.gmane.org/gmane.comp.web.spip.zone/38101

Pour informer du changement oui, pas pour en discuter :

On ajoute le formulaire charter accessible dans la charte, fruit du

> travail combine de goetsu et bennyb

ce formulaire a vocation a devenir la reference

et

> voilà j'ai mis la doc de référence à jour

C'était donc bien entériné avant discussion.
J'avais proposé un mécanisme qui permette de débrayer pour assurer une compat ascendante, Cedric m'a répondu qu'il fallait migrer.

Et il n'y a pas eu d'annonce pour expliquer cette rupture de compat, ce que ça implique et les modifications à apporter aux plugins.
On ne peut pas supposer que tout le monde lise _tous_ les messages des listes et _tous_ les logs de commits pour deviner qu'il y a une nouvelle référence à suivre.

7

Oui c’était assez entériné effectivement.

Mais pour la rupture de compat que ça peut créer, c’est soit l’assumer dans la version SPIP3.1 en développement, soit créer une nouvelle branche de développement SPIP3.2 pour y mettre cette feature.

SPIP 3.1, même labellisé “version beta”, est dans une branche de développement donc à mes yeux c’est normal que cette branche puisse casser
Si on veut vraiment stabiliser SPIP 3.1, commençons d’abord par en faire une branche beta.

8

Hop,

Mais pour SPIP il n'y a pas de différence entre la branche "beta" et la
branche "développement".
Comment fait-on actuellement pour préparer une version 3.2 ?
On ne peut rien faire tant que la branche 3.1 n'existe pas dans le dépôt
svn.

Un peu de patience, il suffit d'attendre qu'on ait releasé la version 3.1. Pour info, il reste encore pas mal de tickets à résoudre sur cette branche avant de se lancer tête baissée dans le chantier 3.2.

Je propose donc, pour que d'autres incompatibilités surviennent, qu'une
branche 3.1 soit créée, et que le trunk devienne une 3.2-dev

Je pense que non, il faut amha attendre qu'on release la 3.1, et ensuite on pourra se lancer dans le chantier 3.2.

PS : on diverge du sujet initial du fil là...

9

Je vois 2/3 choses :
- Le changement semble important pour l'accessibilité
- Il ne casse pas trop de chose (faut relativiser tout de même, si ce n'est la validité HTML dans certains cas)
- Les corrections sont simples : ajouter la classe editer-groupe.
- Il y a seulement si le plugin est compat 3 et 3.1 (c'est souvent le cas) que [(#VAL{ul}|saisie_balise_structure_formulaire)] est utilisé, et est un peu vilain. Il y a peut être une amélioration à trouver pour ça. [(#DIV|sinon{ul})] ?

Il ne faut pas trop se leurrer aussi, si la 3.2 met autant de temps que la 3.1 à sortir, il y a peu de chance que l'accessibilité fut améliorée avant encore 2 ans… Ce qui semble dommage du coup.

Enfin, les discussions aboutissent souvent sur "on ne fait pas pour pas casser l'existant" ou sur "pour la 3.2" (c'est à dire… dans longtemps ; et le même problème se reposera de toutes façons).

Il faut aussi un peu de courage du coup pour bouger le code SPIP. Quoiqu'on fasse, on se fait rentrer dedans. Si on discute ça va pas (c'est trop tôt, c'est pas le moment, c'est mal expliqué, c'est pas assez abouti, faut faire bien mieux, faut faire parfait, etc.), si on fait ça va pas, et si on fait pas ça va pas (encore que).

C'est sans issue. Ça finit souvent en statut quo, puisque ne rien faire devient de facto la meilleure solution.

Est-ce que chacun fait une discussion avant chaque commit qu'il envoie sur la zone qui modifie son plugin ?

Un truc c'est que le temps semble souvent incompatible avec les discussions : si j'ai l'idée d'améliorer (au pif) Champs Extras Interface pour ajouter un import / export. J'ai l'idée, j'ai le temps, je le fais. Si au moment où j'ai ce temps, je lance une discussion sur le sujet, pour l'expliquer, pour demander si je le fais dans le plugin ou dans un plugin tierce, pour ceci cela. Lorsque les gens ont répondu, je tombe sur une période… où je suis passé à une autre motivation ; et il y a peu de chance que quelqu'un fasse ce que je souhaitais (où quelque chose de mieux qui aurait été proposé) à ma place.

C'est sûr que c'est mieux d'annoncer ce qu'on compte faire. D'échanger, de discuter pour voir si c'est le bon moment ou si c'est à faire pour plus tard, ou avec plus d'ambition. Mais au bout de ça, le résultat c'est souvent rien de concret justement, et beaucoup de démotivation. Enfin rien. C'est riche des discussions, des échanges, plein de pistes, de yakafokon, des idées, des todos ; plein de belles choses aussi, mais qui n'aboutissent pas ou rarement au final.

On peut dire par exemple que ce changement est ridicule pour l'accessibilité en général, car c'est tout l'espace privé qu'il faudrait revoir et améliorer, et c'est certainement vrai. C'est simple à amener dans une discussion, et ça amène finalement à ne rien faire, parce que refaire l'espace privé c'est une autre paire de manche. Là il y a au moins une petite marche qui améliore la situation.

MM.

10

Bonjour a tous,

pas souvent present sur IRC, et "ne passant pas mon temps a re-lire le code" pour suivre les modifs,
je reprendrais volontiers la demande rappelée par Jacques, de documenter....
   Je voudrais citer en exemple les récents travaux de Teddy (ses articles Contrib 4488 + 4698 + 4699,
sans oublier http://teddypayet.com/Squelettes-Z-core-sous-SPIP-3 )
qui documentent de façon plus "utilisable" cette pratique Z assez exemplaire /merci Cedric/
alors meme que beaucoup y restent rétifs, la jugeant trop complexe.....
    Et le résumé ci-dessus fourni par Matthieu est aussi fort utile :
    dommage que nous ne soyons pas encore équipés pour fournir ces analyses
    de façon facile à identifier /puis facile à produire.../ avec SPN ?
Bravo a ceux-ci, et merci !

11

Je plussoie à ce que dit Matthieu.

12

Yo Matthieu,

13

salut,
de mon côté je comprenais que le principe “gogogo! on discute après” était évoqué par Mathieu, beaucoup plus simplement et sans arrières pensées…

14

Je me trompe certainement, d'une part, et d'autre part ce que j'ai dit n'est pas forcément consensuel. Mais doit-on prévenir à chaque fois qu'on va faire quelque chose ?

Ce que j'essaie de signaler, c'est que le changement introduit me semble plutôt positif et ne casse pas autant de choses que cela. Même si oui, on a du repasser derrière certains plugins pour adapter légèrement suite à cette modification. Peut être que je me trompe en pensant que cette modification n'est pas critique.

Dois-je informer à chaque fois que je vais corriger des notices PHP sur tel fichier du Core ou d'un plugin (et que parfois je me rate en plus en le faisant – c'est vécu) ? À chaque fois que je compte faire quelque chose sur un plugin qui est déposé sur la zone, que j'en sois un des auteurs ou non ? Et sinon quel est le point limite qui rend la discussion obligatoire ? Et enfin dans une discussion, à partir de quel moment (nombre de réponses, temps écoulé, validation ou non et par qui, documentation écrite à l'avance…) puis-je intervenir du coup ? Et si j'avais prévu ce volume de travail, disons d'y passer 4h et que les discussions amènent à quelque chose de vachement mieux (et oui c'est souvent le cas je te l'accorde) mais qui prennent 10 jours, qui va le faire ?

Ce sont de vrais questions. Peut être que la réponse est oui ; qu'il faut réfléchir et discuter ensemble avant toute modification sur SPIP ou sur la zone.

Le point de tension pour le cas qui nous occupe ici, il me semble, c'est qu'il est introduit dans une version 3.1 béta. Et béta semble signaler qu'il ne devrait y avoir que des corrections de bugs ; que toutes les nouvelles fonctionnalités ou changements sont présents et figés. Je fais ce constat que si ça ne devait pas être introduit dans cette version 3.1 pour ces raisons, cela pouvait entrer dans la prochaine 3.2. Et vraisemblablement donc, ça inclurait 2 ans d'attente à notre rythme habituel. (ou pas, qui sait… c'est juste une hypothèse probable…). Alors qu'est-ce qu'il vaut mieux ? oui en discuter, je sais.

Bah c'est ce qu'on fait :slight_smile:

MM.

15

Hi,

Je reste convaincu que nous avons eu tort de ne pas brancher tous les plugins lors de la 3.0 et d’ainsi de se débarrasser de toute une cohorte de vieux concepts remplacés avantageusement comme le plugin.xml.

Après, quelle incompatibilité s’autoriser ? Ou est la limite entre j’y vais et je discute comme le demande Marcimat.
Ben c’est assez simple amha, qui est capable de le faire ?

Maintenant, si personne ne s’était autorisé des évolutions dans SPIP où en serions-nous ?

C’est vrai qu’il n’y a pas d’obligation de résultat dans SPIP mais nous ne sommes pas tous intéressés par faire des sites.

Moi c’est SPIP et son code PHP qui m’intéresse mais malheureusement je n’ai pas toujours la capacité de produire entièrement des évolutions et c’est donc pour cela que je fais appel à la discussion. Mais force est de constater que ça abouti assez peu.

Si j’étais plus autonome je serais surement enclin à faire les modifications plus “autoritairement” ne serait-ce que pour les tester vraiment.

En tout cas il reste des bugs et des tickets dans la 3.1 et il serait bien de la sortir rapidement pour tout péter ensuite :stuck_out_tongue: !

16

Hello,

je reviens au message initial et au fond du débat.

Concernant le core :
- la structure des formulaires en ul/li a été critiquée à plusieurs reprises ces dernières années pour sa verbosité excessive dans les lecteurs d'écrans et s'est avérée pas du tout idéale en terme d'accessibilité
- un travail préalable d'amélioration avait été fait par Goetsu et Bennyb, et commité dans le plugin dev, en attente d'intégration, consistant essentiellement à tout passer en div
- le passage de tous les formulaires du core en div ne provoque qu'une incompatibilité mineure, sur les quelques plugins qui font des preg sur les formulaires pour s'insérer dedans, ce qui se corrige trivialement
- hormis ce cas, cela ne casse rien. Tous les formulaires existants en ul/li continuent de fonctionner très bien. Actuellement ils on un petit défaut visuel sur le padding car j'ai enlevé le style porté direct par les ul pour inciter à poser la class editer-groupe.
*On peut remettre ce style comme il était si on préfère, pour que les formulaires en ul/li soient strictement supportés sans aucun impact*
- on bénéficie du gain d'accessibilité lié à la mise à jour de la structure des formulaires

Sur la forme :
- j'ai considéré la modif du core selon les recommandations de Goetsu comme assez mineure, le changement de balise recommandée ayant peu d'impact comme indiqué ci-dessus.
Peut-être ai-je eu tort ?

- le timing n'est pas idéal j'en conviens, il aurait été préférable de faire cela plus en amont, avant la phase beta. Il m'a semblé que vu le peu d'impact cela valait la peine de faire passer cette correction dans la 3.1 plutôt que d'attendre encore 2 ans avant une prochaine release.

- il n'y a pas mort d'homme, tout cela est très mineur, et il est trivial de faire un revert sur le core si cela vous embête et que tout le monde préfère ne rien toucher dans la 3.1

Concernant le plugin saisies :
Je crois comprendre que c'est surtout là que ça coince car cela entraine plus de modification sur les plugins existant.

La mise en place des div par défaut au lieu de ul/li dans le plugin saisies est totalement indépendant de la modification du core.

Je n'avais pas prévu d'y toucher, mais je l'ai faite dans la foulée suite à discussion avec Mathieu, l'intérêt étant de faire bénéficier un maximum de monde de la structure plus accessible, et notamment tous les formulaires publics générés avec des saisies, mais elle n'a aucun caractère obligatoire.
On peut améliorer l'écriture compatible 3.0/3.1, décider de garder les ul par défaut et les div activables, ou au contraire, ou de tout revert pour laisser le temps aux dev des plugins de se mettre à jour.

On fait d'abord et on s'engueule après. J'aime qu'un plan se déroule sans accroc.

17

Hop, je remonte le thread...