afficher_si ne fonctionne pas pour un formulaire ouvert dynamiquement #154

Open
opened 3 weeks ago by rastapopoulos · 9 comments

Il semblerait que le javascript ne soit inséré que si un formulaire existe déjà dans la page de base. Si un formulaire est chargée dynamiquement, par exemple dans une box ou en ajax : pas de JS ajouté = pas de afficher_si du tout.

Pourtant les onglets et les fieldsets pliables, qui eux aussi sont en JS fourni par saisies, eux fonctionnent (par ex les forums d'édition de noisette). C'est pas inséré pareil ?

Il semblerait que le javascript ne soit inséré que si un formulaire existe déjà dans la page de base. Si un formulaire est chargée dynamiquement, par exemple dans une box ou en ajax : pas de JS ajouté = pas de afficher_si du tout. Pourtant les onglets et les fieldsets pliables, qui eux aussi sont en JS fourni par saisies, eux fonctionnent (par ex les forums d'édition de noisette). C'est pas inséré pareil ?
Collaborator

Il me semble que c'est affichage_final qui le fait non?

En tt cas ce que tu relève avait été signalé par @nicod_ et cela avait donné #76 et l'ajout d'une option pour charger systématiquement le js

Il me semble que c'est affichage_final qui le fait non? En tt cas ce que tu relève avait été signalé par @nicod_ et cela avait donné #76 et l'ajout d'une option pour charger systématiquement le js
Poster

Je n'avais pas suivi la fin, ok…

Alors deux choses :

  • Il me semble que cette option vaut essentiellement pour le site public, car c'est là où la proportion de formulaire (et plus encore de forms chargés dynamiquement) change complètement suivant les squelettes des gens. Moi là je parle surtout d'utilisation dans l'admin, qui est rempli de forms partout, dont certains peuvent être dynamiques (noisettes, documents, insérer modèles, etc). Il me semble que là c'est pas du tout du ressort des propriétaires du site, c'est bien à Saisies où aux plugins qui ont des forms en box/ajax de s'assurer que JS et CSS sont toujours dispos. Donc soit Saisies doit l'insérer partout pour l'admin d'office (surement le plus simple), soit ces plugins doivent pouvoir lever un drapeau define pour ça.
  • Deuxièmement, je ne vois pas pourquoi ce choix d'un form de config par interface ("parce que c'est ça dans d'autres plugins"). Concrètement : en quoi le rôle admins de site aurait forcément le savoir de comment le site est fait techniquement ? Pour moi c'est très exactement le même principe que l'activation du mode "HTML5" : c'est aux devs/intés de savoir si les squelettes ont besoin de ça (car le site public chargerait des forms dynamiquement), soit aux devs de plugins qui chargent des forms dynamiquement (y compris en public parfois), de pouvoir activer ce chargement permanent. Donc forcément par un drapeau à lever, et pas en comptant sur le fait que les admins doivent 1) savoir ça, ce qui est déjà hautement improbable, et 2) s'en souvenir à chaque fois.

Donc en résumé :

  • pour l'admin ça devrait sûrement être chargé (et compressé) 100% du temps.
  • pour le public, ça devrait être activé par les devs uniquement donc par un drapeau.
Je n'avais pas suivi la fin, ok… Alors deux choses : - Il me semble que cette option vaut essentiellement *pour le site public*, car c'est là où la proportion de formulaire (et plus encore de forms chargés dynamiquement) change complètement suivant les squelettes des gens. Moi là je parle surtout d'utilisation dans l'admin, qui est rempli de forms partout, dont certains peuvent être dynamiques (noisettes, documents, insérer modèles, etc). Il me semble que là c'est pas du tout du ressort des propriétaires du site, c'est bien à Saisies où aux plugins qui ont des forms en box/ajax de s'assurer que JS et CSS sont toujours dispos. Donc soit Saisies doit l'insérer partout pour l'admin d'office (surement le plus simple), soit ces plugins doivent pouvoir lever un drapeau define pour ça. - Deuxièmement, je ne vois pas pourquoi ce choix d'un form de config par interface ("parce que c'est ça dans d'autres plugins"). Concrètement : en quoi le rôle admins de site aurait forcément le savoir de comment le site est fait techniquement ? Pour moi c'est très exactement le même principe que l'activation du mode "HTML5" : c'est aux devs/intés de savoir si les squelettes ont besoin de ça (car le site public chargerait des forms dynamiquement), soit aux devs de plugins qui chargent des forms dynamiquement (y compris en public parfois), de pouvoir activer ce chargement permanent. Donc forcément par un drapeau à lever, et pas en comptant sur le fait que les admins doivent 1) savoir ça, ce qui est déjà hautement improbable, et 2) s'en souvenir à chaque fois. Donc en résumé : - pour l'admin ça devrait sûrement être chargé (et compressé) 100% du temps. - pour le public, ça devrait être activé *par les devs uniquement* donc par un drapeau.
Collaborator

Hum. Je sais pas. Meme pour le privé l'insertion auto sur 100% des pages se discute.

Par exemple si j'active saisies juste pour créer un formulaire formidable, pas forcément utile d'avoir partout. Et même pour un plugin qui s'appuierait sur saisies pour ses propres formulaires, il y a peut-être juste une ou deux pages concernées.

Je crois que le choix de la case a cocher côté public était lié au fait qu'on pensait historiquement à un cas d'usage avec formidable et donc ça relèvait de l'editorial. Mais oui parfois ce sont des formulaires de squelettes qui sont concernés et ça relève alors du squelette, et donc d'un define.

Du coup bah je sais pas. Une case + un define avec un or ?

Hum. Je sais pas. Meme pour le privé l'insertion auto sur 100% des pages se discute. Par exemple si j'active saisies juste pour créer un formulaire formidable, pas forcément utile d'avoir partout. Et même pour un plugin qui s'appuierait sur saisies pour ses propres formulaires, il y a peut-être juste une ou deux pages concernées. Je crois que le choix de la case a cocher côté public était lié au fait qu'on pensait historiquement à un cas d'usage avec formidable et donc ça relèvait de l'editorial. Mais oui parfois ce sont des formulaires de squelettes qui sont concernés et ça relève alors du squelette, et donc d'un define. Du coup bah je sais pas. Une case + un define avec un or ?
Poster

Mais même si les seuls formulaires du site public étaient des Formidable, ça n'a pas de rapport avec quels formulaires, mais bien comment ils sont insérés donc forcément en rapport avec les squelettes, avec l'intégration.

Le fait de vouloir insérer les JS tout le temps, ce n'est pas "parce qu'il y aurait beaucoup de formulaires", mais bien pour que ça marche quand les forms arrivent dynamiquement dans une page (= en ajax, que ce soit box ou autre). Donc c'est intégralement et uniquement du ressort des devs/intés, je ne vois vraiment aucun cas où ça serait du ressort des admins/éditorial.

Mais même si les seuls formulaires du site public étaient des Formidable, ça n'a pas de rapport avec *quels formulaires*, mais bien *comment ils sont insérés* donc forcément en rapport avec les squelettes, avec l'intégration. Le fait de vouloir insérer les JS tout le temps, ce n'est pas "parce qu'il y aurait beaucoup de formulaires", mais bien pour que ça marche *quand les forms arrivent dynamiquement* dans une page (= en ajax, que ce soit box ou autre). Donc c'est intégralement et uniquement du ressort des devs/intés, je ne vois vraiment aucun cas où ça serait du ressort des admins/éditorial.
Collaborator

Oui et non.

En fait :

  1. Au tout début on penserait tout le temps
  2. Puis Cédric a dit "plein de js tout le temps pour peu d'usage c'est pas terrible en terme de perf" et on s'est mis à insérer au cas par cas.
  3. Puis nova vu le pb Ajax et on a rouvert le dossier. Sauf que du coup il y avait 2 raisons pour laquelle on pouvait vouloir insérer tout le temps :
    a. Pour l'ajax
    b. Pour perf pour disposer du compresseur

Et dans noyau réflexion on a tenu compte de b. mais pas de a.

Mais effectivement il faudrait tenir compte de a. Et donc permettre que ce soit aussi au squelette de définir l'insertion systématique.

Oui et non. En fait : 1. Au tout début on penserait tout le temps 2. Puis Cédric a dit "plein de js tout le temps pour peu d'usage c'est pas terrible en terme de perf" et on s'est mis à insérer au cas par cas. 3. Puis nova vu le pb Ajax et on a rouvert le dossier. Sauf que du coup il y avait 2 raisons pour laquelle on pouvait vouloir insérer tout le temps : a. Pour l'ajax b. Pour perf pour disposer du compresseur Et dans noyau réflexion on a tenu compte de b. mais pas de a. Mais effectivement il faudrait tenir compte de a. Et donc permettre que ce soit aussi au squelette de définir l'insertion systématique.
Poster

Mais on sait aussi charger du JS dynamiquement : GIS le fait.

Plutôt que de charger sur toutes les pages parce qu'une ou deux pages font apparaitre un form en ajax, est-ce qu'il ne pourrait pas y avoir un algo du genre :

  • par défaut, le plugin détecte s'il y a des saisies dans la page de départ, et insère du JS en plus seulement dans ce cas
  • une option, en define et en interface (même si ça me parait le moins courant) permet d'insérer JS en permanence sans condition aucune (ça c'est pour la perf pour les sites qui savent avoir des forms vraiment partout)
  • dans le code final de tout formulaire ayant au moins une saisie (donc page de départ ou apparition ajax, et formulaire 100% saisies ou champs extras aussi) : un mini code JS très rapide devrait détecter si le JS de saisies a déjà été inséré avant dans la page, à priori avec de la détection de feature (tester l'existence d'une fonction marquante par exemple), et SI c'est pas le cas : charger le JS supplémentaire dynamiquement en JS directement (et si un autre form apparait plus tard dans le temps en ajax aussi : ça devrait détecter que le JS est déjà chargé).

SPIP core mériterait vraiment une API dédiée à ces problématiques de chargement JS, en sachant permettre/gérer/détecter tous les cas, insertion permanente, insertion dans la page de départ, et insertion dynamique MAIS toujours unique.

Mais on sait aussi charger du JS dynamiquement : GIS le fait. Plutôt que de charger sur toutes les pages parce qu'une ou deux pages font apparaitre un form en ajax, est-ce qu'il ne pourrait pas y avoir un algo du genre : - par défaut, le plugin détecte s'il y a des saisies dans la page de départ, et insère du JS en plus seulement dans ce cas - une option, en define et en interface (même si ça me parait le moins courant) permet d'insérer JS en permanence sans condition aucune (ça c'est pour la perf pour les sites qui savent avoir des forms vraiment partout) - dans le code final de tout formulaire ayant *au moins une saisie* (donc page de départ ou apparition ajax, et formulaire 100% saisies ou champs extras aussi) : un mini code JS très rapide devrait détecter si le JS de saisies a *déjà été* inséré avant dans la page, à priori avec de la détection de feature (tester l'existence d'une fonction marquante par exemple), et SI c'est pas le cas : charger le JS supplémentaire dynamiquement en JS directement (et si un autre form apparait plus tard dans le temps en ajax aussi : ça devrait détecter que le JS est déjà chargé). SPIP core mériterait vraiment une API dédiée à ces problématiques de chargement JS, en sachant permettre/gérer/détecter tous les cas, insertion permanente, insertion dans la page de départ, et insertion dynamique MAIS toujours unique.
Poster

Alors le dernier message vaut surtout pour la partie publique (même si ces différentes manières peuvent aussi s'appliquer à l'admin pour être super pointilleux).

MAIS, là en l'occurence pour mon problème de départ : je vois que afficher_si.js est DEJA inséré en permanence dans header_prive !

Et pourtant :

  • quand le form est directement dans une page dédiée, ça marche, ça masque des champs etc
  • quand le forum est chargé en ajax dans une box, ça ne marche pas du tout, alors donc que le JS est bien dans la page complète dès le départ

Donc il y a encore un autre problème supplémentaire à priori : l'initialisation du "scan" de la page pour trouver des afficher_si à masquer, binder des events sur des champs etc, ne se lance PAS quand un truc arrive en ajax. Ça doit scanner au démarrage de la page et plus jamais ensuite, dirait-on.

Alors le dernier message vaut surtout pour la partie publique (même si ces différentes manières peuvent aussi s'appliquer à l'admin pour être super pointilleux). MAIS, là en l'occurence pour mon problème de départ : je vois que afficher_si.js est DEJA [inséré en permanence dans header_prive](https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/saisies_pipelines.php#L31) ! Et pourtant : - quand le form est directement dans une page dédiée, ça marche, ça masque des champs etc - quand le forum est chargé en ajax dans une box, ça ne marche pas du tout, alors donc que le JS est bien dans la page complète dès le départ Donc il y a encore un autre problème supplémentaire à priori : l'initialisation du "scan" de la page pour trouver des afficher_si à masquer, binder des events sur des champs etc, ne se lance PAS quand un truc arrive en ajax. Ça doit scanner au démarrage de la page et plus jamais ensuite, dirait-on.
Owner

Dans saisies.js ça relance la machine avec onAjaxLoad :

onAjaxLoad(saisies_fieldset_pliable);
onAjaxLoad(saisies_fieldset_onglet);
onAjaxLoad(saisies_multi_novalidate);

Tandis que dans saisies_afficher_si.js, ça utilise ajaxComplete

$(document).ajaxComplete(function() {
	afficher_si_init();
});

C'est pas ça le problème ?

Dans saisies.js ça relance la machine avec [onAjaxLoad](https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/saisies_pipelines.php#L31) : ```js onAjaxLoad(saisies_fieldset_pliable); onAjaxLoad(saisies_fieldset_onglet); onAjaxLoad(saisies_multi_novalidate); ``` Tandis que dans saisies_afficher_si.js, ça utilise [ajaxComplete](https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/javascript/saisies_afficher_si.js#L4) ```js $(document).ajaxComplete(function() { afficher_si_init(); }); ``` C'est pas ça le problème ?
Poster

Juste pour mémoire et lien, à propos de la documentation (ou la fourniture d'une API) pour faciliter à tout le monde les différentes 2 ou 3 manières d'insérer du JS, yavait ce ticket du core : spip/spip#3229

Juste pour mémoire et lien, à propos de la documentation (ou la fourniture d'une API) pour faciliter à tout le monde les différentes 2 ou 3 manières d'insérer du JS, yavait ce ticket du core : https://git.spip.net/spip/spip/issues/3229
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.