Afficher_si côté JS: optimiser encore un peu les choses #51

Closed
opened 2 years ago by maieul · 4 comments
maieul commented 2 years ago
Owner

Tentative de synthèse suite discussion IRC avec @tcharlss et @rastapopoulos.

Résumé

Il faudrait modifier la manière dont les afficher_si sont gérés côté JS histoire de pouvoir trouver automatiquement la valeur des champs à comparer.

Limite du système actuel

Avec le système actuel, si on crée un nouvel saisie qui ne produit pas un bete input html, il faut nécessairement déclarer "à la main" le type d'input, via un pipeline, car la détermination du test JS à effectuer se fait en PHP, dans la fonction saisies_afficher_si_js(). Cette fonction renvoie un test js qui est stocké dans data-afficher-si. Ce test JS est ensuite evaluer avec eval() en JS.

Le pipeline en question est saisies_afficher_si_js_type.

spip-contrib-extensions/agenda#26/files

On a également besoin du pipeline saisies_afficher_si_js_saisies_form pour les pseudos-saisies comme @evenement_xxx_liste_attente@ (pseudo saisie : saisie qui n'est pas décrite dans le formulaire, mais qui est "intégré" dans une saisie standard, généralement variante en JS, et qui est dynamique).

Proposition

  1. La fonction PHP saisies_afficher_si_js() renverrait plutôt une expression js de type afficher_si(<paramètres>) ou encore afficher_si(<paramètres tests 1>) || afficher_si(<paramètres tests 2>) dans le cas des tests composés.
    a. La liste des paramètres de cette fonction dépend de la syntaxe officielle des tests https://contrib.spip.net/Affichage-conditionnel-de-saisie-syntaxe-des-tests
    b. Il est assez facile de trouver ces paramètres, vu que c'est plus ou moins ce que renvoie saisies_parser_condition_afficher_si().
  2. La fonction JS afficher_si(paramètres)
    a. Renvoi un booléen
    b. S'appuie sur la fonction jQuery https://api.jquery.com/serializearray/
    c. Repère les saisies à partir du data-id plutôt que du name directement pour répondre à #45

Limites de la proposition

Je vois pour l'heure 2 limites, mais elles sont mineures :

  • serializeArray() ne gère pas les input de type file, mais bon ca à la limite on peut sans doute trouver un code dérogatoire
  • le pipeline saisies_afficher_si_js_saisies_form sert aussi dans FORMIDABLE pour permettre d'afficher les pseudo saisies dans l'aide memoire depuis dd673b6baf

cf capture d'écran

Tentative de synthèse suite discussion IRC avec @tcharlss et @rastapopoulos. # Résumé Il faudrait modifier la manière dont les afficher_si sont gérés côté JS histoire de pouvoir trouver automatiquement la valeur des champs à comparer. # Limite du système actuel Avec le système actuel, si on crée un nouvel saisie qui ne produit pas un bete input html, il faut nécessairement déclarer "à la main" le type d'input, via un pipeline, car la détermination du test JS à effectuer se fait en PHP, dans la fonction `saisies_afficher_si_js()`. Cette fonction renvoie un test js qui est stocké dans data-afficher-si. Ce test JS est ensuite evaluer avec `eval()` en JS. Le pipeline en question est `saisies_afficher_si_js_type`. https://git.spip.net/spip-contrib-extensions/agenda/pulls/26/files On a également besoin du pipeline `saisies_afficher_si_js_saisies_form` pour les pseudos-saisies comme `@evenement_xxx_liste_attente@` (pseudo saisie : saisie qui n'est pas décrite dans le formulaire, mais qui est "intégré" dans une saisie standard, généralement variante en JS, et qui est dynamique). # Proposition 1. La fonction PHP `saisies_afficher_si_js()` renverrait plutôt une expression js de type `afficher_si(<paramètres>)` ou encore `afficher_si(<paramètres tests 1>) || afficher_si(<paramètres tests 2>)` dans le cas des tests composés. a. La liste des paramètres de cette fonction dépend de la syntaxe officielle des tests https://contrib.spip.net/Affichage-conditionnel-de-saisie-syntaxe-des-tests b. Il est assez facile de trouver ces paramètres, vu que c'est plus ou moins ce que renvoie saisies_parser_condition_afficher_si(). 2. La fonction JS afficher_si(paramètres) a. Renvoi un booléen b. S'appuie sur la fonction jQuery https://api.jquery.com/serializearray/ c. Repère les saisies à partir du data-id plutôt que du name directement pour répondre à #45 # Limites de la proposition Je vois pour l'heure 2 limites, mais elles sont mineures : - serializeArray() ne gère pas les input de type file, mais bon ca à la limite on peut sans doute trouver un code dérogatoire - le pipeline `saisies_afficher_si_js_saisies_form` sert aussi dans FORMIDABLE pour permettre d'afficher les pseudo saisies dans l'aide memoire depuis https://git.spip.net/spip-contrib-extensions/formidable/commit/dd673b6baff8a6d99b01c9d0962828c706fea373 cf capture d'écran
Poster
Owner

Arf, en fait ca peut pas résoudre #45, bien au contraire, puisque https://api.jquery.com/serializearray/ renvoi un tableau se basant sur les names, et que précisement ce sont eux qui sont chiffrés avec define('_SPAM_ENCRYPT_NAME', true); qui est le problème de #45.

Le problème c'est que ce chiffrement se fait côté PHP une fois l'ensemble du form codé (et pour cause !). Du coup côté JS on n'a plus d'équivalence entre le name réel et les @@ des afficher_si.

Mais pour aller plus loin j'ai besoin des compétences de @cerdic_.

Est-ce qu'il y aurait un moyen d'avoir accès (en PHP bien sûr) à la forme chiffrées des names AVANT lque l'ensemble du formulaire soit construit, au moment où l'on ajoute une saisie ?

Ou bien est-ce qu'il y aurait moyen soit directement dans nospam, soit via un pipeline a ajouter à nospam_encrypt_form_names(), d'appliquer des traitements supplémentaires après le cryptage des names (par exemple : rechercher pour chaque name crypté ses occurences dans les champs data-afficher-si).

Arf, en fait ca peut pas résoudre #45, bien au contraire, puisque https://api.jquery.com/serializearray/ renvoi un tableau se basant sur les names, et que précisement ce sont eux qui sont chiffrés avec `define('_SPAM_ENCRYPT_NAME', true);` qui est le problème de #45. Le problème c'est que ce chiffrement se fait côté PHP une fois l'ensemble du form codé (et pour cause !). Du coup côté JS on n'a plus d'équivalence entre le name réel et les @@ des afficher_si. Mais pour aller plus loin j'ai besoin des compétences de @cerdic_. Est-ce qu'il y aurait un moyen d'avoir accès (en PHP bien sûr) à la forme chiffrées des names AVANT lque l'ensemble du formulaire soit construit, au moment où l'on ajoute une saisie ? Ou bien est-ce qu'il y aurait moyen soit directement dans nospam, soit via un pipeline a ajouter à `nospam_encrypt_form_names()`, d'appliquer des traitements supplémentaires après le cryptage des names (par exemple : rechercher pour chaque name crypté ses occurences dans les champs data-afficher-si).
Poster
Owner

Bon,

concernant le problème de #45, j'ai fait une proposition en spip-contrib-extensions/nospam#1. De toute facon le problème est commun à tout.

Du coup je vais m'attaquer à cette issue #51, qui permettra normalement après coup de :

Il y aura un PR + une demande de tests intensif.

Je me note ici les choses à bien penser :

Bon, concernant le problème de #45, j'ai fait une proposition en https://git.spip.net/spip-contrib-extensions/nospam/issues/1. De toute facon le problème est commun à tout. Du coup je vais m'attaquer à cette issue #51, qui permettra normalement après coup de : - résoudre plus facilement #51 - se passer de https://git.spip.net/spip-contrib-extensions/agenda/pulls/26 Il y aura un PR + une demande de tests intensif. Je me note ici les choses à bien penser : - [x] vérifier toutes les syntaxes officielles https://contrib.spip.net/Affichage-conditionnel-de-saisie-syntaxe-des-tests - [x] penser aux cas des saisies dont le name est un tableau, du type `toto[truc][bidule]` - [x] penser aux cas des saisies dont le name est un tableau, du type `toto[]`
maieul referenced this issue from a commit 2 years ago
maieul referenced this issue from a commit 2 years ago
maieul referenced this issue from a commit 2 years ago
Collaborator

J'ai fait quelques tests, je ne vois pas de bug pour l'instant.

Y'a t'il des points particuliers à vérifier ?

J'ai fait quelques tests, je ne vois pas de bug pour l'instant. Y'a t'il des points particuliers à vérifier ?
Poster
Owner

non, là je ne vois pas. Enfin il y avait le checkbox dans ce ticket, mais visibelemtn c'est bon.

Bon bah merci pour les tests. J'essaierai de releaser ce week-end, mais sans doute serai-je pris par le passage en 3.3 des sites plasci (car changement de serveur php très bientot)

non, là je ne vois pas. Enfin il y avait le checkbox dans ce ticket, mais visibelemtn c'est bon. Bon bah merci pour les tests. J'essaierai de releaser ce week-end, mais sans doute serai-je pris par le passage en 3.3 des sites plasci (car changement de serveur php très bientot)
maieul closed this issue 2 years ago
maieul referenced this issue from a commit 2 years ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.