Chers tous, chères toutes,
**Message court**
J'ai créé une branche pour réécrire la manière dont les afficher_si fonctionnaient niveau javascript. Est-ce que des bonnes âmes voudraient bien tester d'ici le 15 septembre ?
C'est la branche
afficher_si_js_reecriture
QUestion subsidiaire : vu que cela peut potentiellement casser des certains cas très particulier, est-ce qu'on fera pas une v.4 ?
**Messsage long**
En décembre j'avais procédé à une réécriture de la partie "vérification PHP" des affichages conditionnelles des saisies.
Le but à l'époque était triple :
- avoir un code plus lisible, et donc plus testable
- définir une bonne fois pour toute une syntaxe propre pour ces tests, en posant AU PREALABLE la syntaxe et A POSTERIORI la transformation en code PHP/JS, et pas, comme cela s'était fait jusqu'a maintenant, en pensant d'abord JS puis en bidouillant un bout de code pour faire venir cela depuis un syntaxe defini à la va vite.
- s'assurer que cette syntaxe ne permettait pas d'executer du code arbitraire (en fait : j'avais oublié un cas, mais c'est corrigé depuis un commit d'aujourd'hui).
Ce travail avait abouti à
- la création d'un parseur d'afficher_si
- la création de fonctions qui depuis le résultat du parsage, produisait un code php puis l'évaluait
Il manquait l'équivalent côté JS, où on se trainait toujours des expressions régulières pas clair. De plus, depuis longtemps, Rasta disait qu'il vaudrait avoir un code JS unique, et des infos stockées en data-afficher-si.
J'ai donc réécrit la partie de js en ce sens, dans une branche à part.
Intérêts :
- gain de performance niveau js :
- on ne teste que les champs qui viennent de changer, et pas tous
- un seul js en cache
- moins de ligne de code envoyées (200 ko sur un cas simple !)
- gain de lisibilité de code, mieux découpé
- tests unitaires pour s'assurer de la perenitté dans le temps
- uniformisation de la syntaxe entre la version PHP et la version JS, en utilisant le même parseur
À terme, possibilité d'ajouter des nouvelles fonctionnalités, en modifiant un peu le parseur et les fonctions filles (je vais faire un article sur contrib) :
- MATCH pour des regexp
- @champ:total@ pour le nombre de case cocher sur des checkbox multiple
- également une fonctionnalité que j'aimerai ajouter : considéré que si un champ est masqué, sa valeur est nul. Il me semble que c'est deja le cas en PHP
Nouveauté en bonus :
- si une condition fait appel à champ qui n'existe pas, elle est ignorée, et un message de log est enregistrée. On le voit plus rapidement
- plus possibilité de programmer un afficher_si pour avoir du code js arbitraire
Ce que cela casse pour les gens :
- si on ne respecte pas strictement la syntaxe décrite dans
https://contrib.spip.net/5080, les tests JS ne fonctionneront pas. Mais de toute facon, cela échouait deja en PHP (mais c'était moins grave, car l'echec ne se voyait que sur les champs obligatoire)
- pour les saisies autonomes, qui n'utilisent pas _base, il faut ajouter data-afficher_si sur le conteneur. Cf https://zone.spip.net/trac/spip-zone/changeset/116067/spip-zone
J'aurais besoin de tests. J'ai deja fait des test avec mes exemples, mais plus on a mieux c'est.
L'idée étant qu'avec l'été, tout ca, on ne merge pas avant le 15 septembre.
Merci de vos retours
Maïeul
