afficher_si_avec_post et verification #92

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

Rappel

afficher_si_avec_post permet que les valeurs d'un champ conditionné par afficher_si ne soient pas perdus au niveau du traitement (et donc conservés en base par ex.).

Problèmes

Imaginons les scénarios suivant

PB 1

a. Une personne commence à remplir un formulaire, avec une saisie conditionné avec afficher_si + afficher_si_avec_post + une contrainte de verification sur afficher_si_avec_post
b. Finalement elle change d'avis, laisse tomber l'option qui permettait d'afficher la saisie conditionée, mais n'a pas le reflexe de vider sa saisie conditionnée

-> La vérification va échouer, elle aura un message d'erreur en retour, mais ne saura pas sur quel champ, car il sera masqué.

PB 2

Dans un formulaire de config, je veux que si on selectionne l'option A1 d'un champ A un champ B apparaisse, permettant par exemple de saisir une clé de service. Ce champ B doit

a. Être obligatoire si A1 est choisi
b. Avoir sa valeur conservée si on bascule à A2, donc j'utilise afficher_si_avec_post.

Mais du coup si je choisi A2 au départ, le champ B n'a pas de valeur, comme il est afficher_si_avec_post et qu'il est obligatoire, ca va couiner au moment de la vérification, mais pareil on verra pas sur quel champ est l'erreur.

Piste de solutions

a. Dans tous les cas je propose qu'un champ qui a un message d'erreur soit systématiquement affiché côté public, même si la condition d'afficher_si n'est pas remplie (ca facilitera le debugage dans le futur si ca arrive)
b. Subsidiairement, l'on pourrait décider (ca prend 3 lignes à bouger) que si une saisie masquée par afficher_si MAIS qu'elle a un afficher_si_avec_post, on ne la vérifie pas (comme c'est le cas si pas d'afficher_si_avec_post).

ping @tcharlss à l'origine d'afficher_si_avec_post :)

## Rappel `afficher_si_avec_post` permet que les valeurs d'un champ conditionné par `afficher_si` ne soient pas perdus au niveau du traitement (et donc conservés en base par ex.). ## Problèmes Imaginons les scénarios suivant ### PB 1 a. Une personne commence à remplir un formulaire, avec une saisie conditionné avec afficher_si + afficher_si_avec_post + une contrainte de verification sur afficher_si_avec_post b. Finalement elle change d'avis, laisse tomber l'option qui permettait d'afficher la saisie conditionée, mais n'a pas le reflexe de vider sa saisie conditionnée -> La vérification va échouer, elle aura un message d'erreur en retour, mais ne saura pas sur quel champ, car il sera masqué. ### PB 2 Dans un formulaire de config, je veux que si on selectionne l'option `A1` d'un champ `A` un champ B apparaisse, permettant par exemple de saisir une clé de service. Ce champ B doit a. Être obligatoire si A1 est choisi b. Avoir sa valeur conservée si on bascule à A2, donc j'utilise afficher_si_avec_post. Mais du coup si je choisi A2 au départ, le champ B n'a pas de valeur, comme il est `afficher_si_avec_post` et qu'il est obligatoire, ca va couiner au moment de la vérification, mais pareil on verra pas sur quel champ est l'erreur. ## Piste de solutions a. Dans tous les cas je propose qu'un champ qui a un message d'erreur soit systématiquement affiché côté public, même si la condition d'`afficher_si` n'est pas remplie (ca facilitera le debugage dans le futur si ca arrive) b. Subsidiairement, l'on pourrait décider (ca prend 3 lignes à bouger) que si une saisie masquée par afficher_si MAIS qu'elle a un `afficher_si_avec_post`, on ne la vérifie pas (comme c'est le cas si pas d'`afficher_si_avec_post`). ping @tcharlss à l'origine d'afficher_si_avec_post :)

b. Subsidiairement, l'on pourrait décider (ca prend 3 lignes à bouger) que si une saisie masquée par afficher_si MAIS qu'elle a un afficher_si_avec_post, on ne la vérifie pas (comme c'est le cas si pas d'afficher_si_avec_post).

Bé c'est surtout ça non ? Une saisie qui est masquée par afficher_si, ne devrait jamais être vérifiée, ni en obligation ni en type de vérif. Mais ça vaut qu'il y ait avec_post ou pas, peu importe, non ?

> b. Subsidiairement, l'on pourrait décider (ca prend 3 lignes à bouger) que si une saisie masquée par afficher_si MAIS qu'elle a un afficher_si_avec_post, on ne la vérifie pas (comme c'est le cas si pas d'afficher_si_avec_post). Bé c'est surtout ça non ? Une saisie qui est masquée par afficher_si, ne devrait *jamais* être vérifiée, ni en obligation ni en type de vérif. Mais ça vaut qu'il y ait avec_post ou pas, peu importe, non ?
Poster
Owner

Bah c'est que je me suis dit aussi spontanément au début, mais je ne savais pas si c'était un bug ou un feature. ALors j'ai hésité, pour voir aussi les réactions :p.

Et je me suis imaginer le scénario suivant

Une saisie B conditionnée par A = 1 et qui doit avoir une valeur > 10.

Je commence par mettre A = 1. Je remplie B = 5. Je me ravis, et met A = 0. Du coup B se masque. J'envoie tout de même B = 5 en base. J'ai quelque chose de pas cohérent. Mais en même temps si j'ai choisi afficher_si_avec_post, je sais que je ne peux pas prendre la valeur de B tel quel, mais qu'il faut que je teste avant A. Donc c'est sans doute à moi de vérifier la cohérence après coup.

Mais j'avais besoin d'avis tier pour être sur de pas me foirer dans ce raisonnement, qui n'est pas si simple que cela.

Bah c'est que je me suis dit aussi spontanément au début, mais je ne savais pas si c'était un bug ou un feature. ALors j'ai hésité, pour voir aussi les réactions :p. Et je me suis imaginer le scénario suivant Une saisie B conditionnée par A = 1 et qui doit avoir une valeur > 10. Je commence par mettre A = 1. Je remplie B = 5. Je me ravis, et met A = 0. Du coup B se masque. J'envoie tout de même B = 5 en base. J'ai quelque chose de pas cohérent. Mais en même temps si j'ai choisi afficher_si_avec_post, je sais que je ne peux pas prendre la valeur de B tel quel, mais qu'il faut que je teste avant A. Donc c'est sans doute à moi de vérifier la cohérence après coup. Mais j'avais besoin d'avis tier pour être sur de pas me foirer dans ce raisonnement, qui n'est pas si simple que cela.
Owner

Moi je dirais un peu du a) et un peu du b) :

  • ne pas vérifier les saisies masquées au moyen de afficher_si.
  • vérifier celles masquées avec afficher_si_avec_post en forçant leur affichage pour voir l'erreur.

Le 2ème point c'est aussi parceque la valeur peut éventuellement être normalisée.

Moi je dirais un peu du a) et un peu du b) : * ne pas vérifier les saisies masquées au moyen de `afficher_si`. * vérifier celles masquées avec `afficher_si_avec_post` en forçant leur affichage pour voir l'erreur. Le 2ème point c'est aussi parceque la valeur peut éventuellement être normalisée.
Poster
Owner

donc en faitr c'est a) seul que propose @tcharlss, puisque qu'actuellement seuls celles avec avec_post sont testées.

donc en faitr c'est a) seul que propose @tcharlss, puisque qu'actuellement seuls celles avec `avec_post` sont testées.

Ah je pensais avoir posté mais non, je disais pareil oui : c'est pas un peu du b) ça, les saisies avec juste afficher_si ne sont déjà pas vérifiées (elles sont vidées totalement donc rien à vérifier).

Donc le seul truc serait : dès qu'un champ a une erreur, il doit être affiché, masqué ou pas.

Ou on peut le dire inversement : un champ ne doit être masqué QUE s'il n'a pas d'erreur affichée. Du coup ça peut même faire gagner en rapidité : pas besoin de générer son afficher_si du tout s'il a une erreur remplie.

Mais du coup je me pose une question : si je change la valeur du champ (ou que je la vide), alors il peut ne plus être en erreur, mais ça on n'en sait rien puisque ça se fait en PHP quand on valide. Mais du coup il reste indéfiniment non masqué tant qu'on n'a pas re-validé. Bon c'est un peu tordu tout ça quand même… Mais bon ça doit être des cas super rares donc bon, on le prend en compte mais on le verra pas souvent dans la vraie vie.

Ah je pensais avoir posté mais non, je disais pareil oui : c'est pas un peu du b) ça, les saisies avec juste afficher_si ne sont déjà pas vérifiées (elles sont vidées totalement donc rien à vérifier). Donc le seul truc serait : dès qu'un champ a une erreur, il doit être affiché, masqué ou pas. Ou on peut le dire inversement : un champ ne doit être masqué QUE s'il n'a pas d'erreur affichée. Du coup ça peut même faire gagner en rapidité : pas besoin de générer son afficher_si du tout s'il a une erreur remplie. Mais du coup je me pose une question : si je change la valeur du champ (ou que je la vide), alors il peut ne plus être en erreur, mais ça on n'en sait rien puisque ça se fait en PHP quand on valide. Mais du coup il reste indéfiniment non masqué tant qu'on n'a pas re-validé. Bon c'est un peu tordu tout ça quand même… Mais bon ça doit être des cas super rares donc bon, on le prend en compte mais on le verra pas souvent dans la vraie vie.
maieul closed this issue 2 years ago
Poster
Owner

Donc pour synthèse

Ce qu'il faut comportement

Une saisie qui est masquées par afficher_si ne devrait jamais être vérifiée, que ce soit avec afficher_si_avec_post ou pas. Si la saisie est masquée, c'est que son résultat n'a pas d'usage immédiat. On peut donc le revérifier au moment où la saisie n'est plus masquées

-> C'est fait.

Ce qui peut arriver si on fait de la merde

Arrivée par le passé, suite à des réécriture côté PHP ou JS des afficher_si. Ine saisie masquées est tout de même vérifier. Sauf que qu'au moment où on raffiche l'erreur, bah la saisie est masquées, du coup les gens ont "ce formulaire contient une erreur", mais ne savent pas où.

Normalement une telle situation ne devrait jamais arrivée. Mais par précaution côté JS : dès lors qu'une saisies à une classe erreur, on laisse tomber de vérifier les conditions, et on l'affiche tjr. (C'est intégré)

Ce qui n'est pas possible de faire

  • Ne pas compiler les afficher_si si la saisie a une erreur, vu que précisement on ne test les erreurs que sur les saisies qui ne sont pas masquées... donc il faut avoir testé au préalable les afficher_si, et on se mordrait la queue
  • Ne generer le code JS des afficher_si que pour les saisies avec erreur. Ce serait possible mais il faudrait stocker quelque part toutes les saisies avec des erreurs, pas sur que cela en vaut la chandelle, surtout que la question se poserait des saisies fieldset.

Ce qu'on peut esperer faire un jour

Avoir un cache interhit sur la compilation des afficher_si. AMAH il faut uniqument un cache memoire, pas un cache disque (la compilation étant essentiellement du regexp). Et même là je suis pas sur que ca vaudrait la peine. (Sachant que par ailleur, on a deja un cache au sein de chaque hit, donc si on vérifie en PHP + on genere en JS, ca compile qu'une fois)

Donc pour synthèse ## Ce qu'il faut comportement Une saisie qui est masquées par afficher_si ne devrait jamais être vérifiée, que ce soit avec `afficher_si_avec_post` ou pas. Si la saisie est masquée, c'est que son résultat n'a pas d'usage immédiat. On peut donc le revérifier au moment où la saisie n'est plus masquées -> C'est fait. ## Ce qui peut arriver si on fait de la merde Arrivée par le passé, suite à des réécriture côté PHP ou JS des afficher_si. Ine saisie masquées est tout de même vérifier. Sauf que qu'au moment où on raffiche l'erreur, bah la saisie est masquées, du coup les gens ont "ce formulaire contient une erreur", mais ne savent pas où. Normalement une telle situation ne devrait jamais arrivée. Mais par précaution côté JS : dès lors qu'une saisies à une classe erreur, on laisse tomber de vérifier les conditions, et on l'affiche tjr. (C'est intégré) ## Ce qui n'est pas possible de faire - Ne pas compiler les afficher_si si la saisie a une erreur, vu que précisement on ne test les erreurs que sur les saisies qui ne sont pas masquées... donc il faut avoir testé au préalable les afficher_si, et on se mordrait la queue - Ne generer le code JS des afficher_si que pour les saisies avec erreur. Ce serait possible mais il faudrait stocker quelque part toutes les saisies avec des erreurs, pas sur que cela en vaut la chandelle, surtout que la question se poserait des saisies fieldset. ## Ce qu'on peut esperer faire un jour Avoir un cache interhit sur la compilation des afficher_si. AMAH il faut uniqument un cache memoire, pas un cache disque (la compilation étant essentiellement du regexp). Et même là je suis pas sur que ca vaudrait la peine. (Sachant que par ailleur, on a deja un cache au sein de chaque hit, donc si on vérifie en PHP + on genere en JS, ca compile qu'une fois)
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.