Holla,
sur la page
https://www.planete-sciences.org/astro/campagne-astronomie/inscription nous avons un formulaire formidable qui utilise massivement les afficher_si. En dehors même du fait qu'on pourrait améliorer certains éléments du formulaire, je ne pense pas qu'on puisse substantiellement simplifier ce formulaire (je connais plutot bien le besoin !).
Depuis qu'on est passé en HTML 5, il y a une latence de 10 secondes à chaque changement de valeur. Pourquoi : à cause des des bascules sur les attributs required.
En effet, à chaque changement dans le formulaire, tous les afficher_si sont testés en JS (j'explique cela en PS). Si la condition d'affichage est rempli, alors .show() est appliqué à la saisie, sinon .hide() est appliqué à la saisie. Cette partie là ne pose pas trop de problème en terme de perf, car on applique cela directement sur la saisie elle-même (sur le div englobant).
En revanche, si, et uniquement si, HTML 5 est autorisé, alors il faut basculer automatiquement les attribut required des input/textarea INCLUENT dans les saisies (donc pas le div englobant). Et c'est là où cela ralentit.
Evidemment, si on pouvait n'executer le js que pour les saisies effectivement impactées par un changement dans le formulaire, ce serait idéal, mais ce n'est pas simple (cf. PS).
En revanche, mon constat est que le ralentissement est essentiellement lié au selecteur jquery utilisé pour impacter les saisies.
Le sélecteur est défini ici
https://zone.spip.net/trac/spip-zone/browser/spip-zone/plugins/saisies/trunk/inc/saisies_afficher_si.php#L131
et permet de couvrir tous les cas de saisies contenant des AFFICHER_SI, quel que soit leur type (textarea, input, etc.).
J'ai fait un test en modifiant rapidement inc/afficher_si.php, de sorte que le selecteur jquery pour la bascule des required corresponde précisément à la saisie concernée par l'afficher_si. Et là le lague devient minime (sachant que mon formulaire est particulièrement complexe). De plus je passe de 64ko de js à 23ko.
Donc j'aurais tendance à dire, allons vers cette piste. MAIS, et c'est là où le bât blesse, étant donné que les saisies, notamment lorsqu'elle sont complexe (date, evenements) peuvent avoir une structure assez particulière, on ne peut se contenter de mon test rapide, et il faudrait que les selecteur jquery dépende de chaque type de saisie, y compris pour les saisie qui ne sont pas livrées avec le plugin.
De plus, dans le cas de la saisie évènements (plugin agenda), les paramètres de la saisie peuvent aussi influencer les selecteur jquery a à émettre, selon la valeur de type_choix.
Du coup, on doit avoir des js saisie individuelle par saisie individuelle. Je vois plusieurs manières de résoudre cela.
1. un squelette js.html pour chaque saisie potentiellement concernée. Avantage : on profite du cache. Inconvénient : on fait beaucoup d'écriture pour pas grand chose.
2. une fonction pour chaque saisie potentiellement concernée
3. un pipeline qui reçois en $flux['data'] le sélecteur jquery et en $flux['arg'] la description de la saisie.
Mes questions sont donc
1. Est-ce que vous voyez d'autres solutions
2. Entre les 3 pistes, laquelle vous semble la plus pertinente
3. Y-a-il moyen d'avoir une liste des plugins qui proposent des saisies supplémentaires pour adapter le cas échéant?
Bises
Amitiés
Maïeul
Ps: pourquoi tout les tests conditionnels sont effectué en JS à chaque changement dans le formulaire, et non pas uniquement celle pour les saisies qui viennent de subir une modif ?
Les afficher_si ce sont des saisies SOURCES qui impactent des saisies CIBLES. Mais ils sont définis saisie CIBLE par saisie CIBLE, et non pas saisies SOURCE saisie CHAMP SOURCE. Et pour cause : pour pouvoir faire cela de manière sélective, en ne testant que les champs (CIBLE) impactés par les modifs d'une saisie SOURCE, il faudrait pourvoir extraire en PHP les saisies SOURCE concernées pour produire des js qui ne fassent les tests que lors que la saisie SOURCE connaît un changement (bascule de select, modif de texte, etc.). C'est pas impossible en théorie, mais je ne suis pas sur que le jeu en vaut la chandelle. En tout cas ce serait un gros poubelle de réécriture coté PHP, je suis pas sur qu'en plus y gagnerait en terme de poids js, et on aurait un js encore plus complexe. Bref, je me lancerai pas dans l'aventure là.
Du reste cet optimisation n'es pas incompatible avec l'optimisation que je propose dans le corps de mail.
Ps2 :
https://framadrop.org/r/nMRDIKaDXk#4QuCwHlvU4fayDH5R9RGd1H2gl72k5Ue5yd1RVSNDm8=
https://framadrop.org/r/RMFAGAMt3K#AMdRwKk+orlbapIGh3QASQNM+nAqkHSa6Gyxt+isSBU=
Le yaml du formulaire + mon saisies_afficher_si modifié
