on m'a signalé un gros formulaire (74 saisies) avec plein de afficher_si (69 conditions) qui ne marchait plus (tous les champs affichés, et une erreur js dans la console).
Vu le nombre, pour identifier celle qui plante j'ai ajouté un console.log(saisie, condition) dans afficher_si.js.html, juste avant le eval()
J'ai donc vu que ça venait de conditions du type @selection_1@=="choix3" && @checkbox_2@=="choix2" avec une des deux saisies qui n'existe plus (parce qu'elle a été supprimée entre temps).
Ça génère donc une condition avec un && tout seul, qui plante le eval().
Comment pourrait on corriger ça ?
- faire de l'analyse de la condition pour supprimer un || ou && en trop ?
bof, casse gueule.
- remplacer les saisies non trouvées par "1 == 1" ?
ça serait glisser la poussière sous le tapis mais ça corrigerait
Lever une alerte au moment de la validation de la saisie ne serait pas suffisant, car une des saisies impliquées dans son afficher_si peut être supprimée après.
Maieul, toi qui connait bien le code, tu as une autre idée avant que je ne corrige ?
Le mardi 01 octobre 2019 à 17:10 +0200, nicod_ a écrit :
Salut,
on m'a signalé un gros formulaire (74 saisies) avec plein de
afficher_si
(69 conditions) qui ne marchait plus (tous les champs affichés, et
une
erreur js dans la console).
Vu le nombre, pour identifier celle qui plante j'ai ajouté un
console.log(saisie, condition) dans afficher_si.js.html, juste avant
le
eval()
J'ai donc vu que ça venait de conditions du type @selection_1@=="choix3"
&& @checkbox_2@=="choix2" avec une des deux saisies qui n'existe plus
(parce qu'elle a été supprimée entre temps).
Ça génère donc une condition avec un && tout seul, qui plante le
eval().
Comment pourrait on corriger ça ?
- faire de l'analyse de la condition pour supprimer un || ou && en
trop ?
bof, casse gueule.
- remplacer les saisies non trouvées par "1 == 1" ?
ça serait glisser la poussière sous le tapis mais ça corrigerait
Les deux solutions cachent le problème sous le tapis, donc sont à mon
avis a proscrire.
hum, compliqué tout ca. Le problème n'est pas technique, mais
ergonomique. La question c'est : comment prevenir qu'il y a un souci
sans que cela se voit pour tout le monde.
Je vois une solution possible : envoyer un email au webmestre signalant
le problème à chaque fois qu'il apparait lors de l'application de
afficher_si_js.
techniquement c'est pas compliqué de vérifier l'existence d'un champ
passé en @@, mais uniquement lorsque toutes les entrées ont été definis,
donc pas lors de la construction du formulaire (sinon on aurait des faux
negatifs)
hum, compliqué tout ca. Le problème n'est pas technique, mais
ergonomique. La question c'est : comment prevenir qu'il y a un souci
sans que cela se voit pour tout le monde.
Bah non là question est pas que ergonomique, et faut pas que prévenir,
c'est les deux.
Car ça change rien au problème : là si une personne supprime un champ,
en partie publique le formulaire est *totalement pété*, et ça ça ne
devrait pas arriver du tout.
Donc il faut bien aussi une correction qui fait que ça ne génère pas
d'erreur après compilation.
hum, compliqué tout ca. Le problème n'est pas technique, mais
ergonomique. La question c'est : comment prevenir qu'il y a un souci
sans que cela se voit pour tout le monde.
Bah non là question est pas que ergonomique, et faut pas que prévenir,
c'est les deux.
Car ça change rien au problème : là si une personne supprime un champ,
en partie publique le formulaire est *totalement pété*, et ça ça ne
devrait pas arriver du tout.
Donc il faut bien aussi une correction qui fait que ça ne génère pas
d'erreur après compilation.
Exactement, il y a le souci de prévenir la personne qui gère le formulaire, et de pas le péter sur le front.
A mon avis, prévenir :
- au moment de la suppression d'une saisie, en vérifiant si elle est utilisée en affiché si
- au moment de la validation d'une saisie, si son afficher_si contient une saisie introuvable
Et sur le front, ajouter une condition true pour éviter l'erreur ?
Ce problème n'apparaissait pas avant la refonte, je crois pas qu'on puisse couper à le régler.
hum, compliqué tout ca. Le problème n'est pas technique, mais
ergonomique. La question c'est : comment prevenir qu'il y a un souci
sans que cela se voit pour tout le monde.
Bah non là question est pas que ergonomique, et faut pas que prévenir,
c'est les deux.
Car ça change rien au problème : là si une personne supprime un champ,
en partie publique le formulaire est *totalement pété*, et ça ça ne
devrait pas arriver du tout.
Donc il faut bien aussi une correction qui fait que ça ne génère pas
d'erreur après compilation.
Exactement, il y a le souci de prévenir la personne qui gère le formulaire, et de pas le péter sur le front.
A mon avis, prévenir :
- au moment de la suppression d'une saisie, en vérifiant si elle est utilisée en affiché si
ca ce serait possible oui
- au moment de la validation d'une saisie, si son afficher_si contient une saisie introuvable
c'est plus compliqué, car par ex si tu crée un formulaire formidable avec juste deux saisies, toi, humain peux savoir le nom de la première saisie avant même qu'elle ne soit enregistré, mais pas le vérificateur,
Et sur le front, ajouter une condition true pour éviter l'erreur ?
pourquoi pas, mais il faut régler aussi en php. Et surtout, c'était le sens de mon propos, il faut d'abord regler cela en terme de prevenir les personnes, ne pas masquer les infos.
Ce problème n'apparaissait pas avant la refonte, je crois pas qu'on puisse couper à le régler.
disons que la refonte a defini de manière plus strictre des règles et que des choses qui passaient avant passent plus
A mon avis, prévenir :
- au moment de la suppression d'une saisie, en vérifiant si elle est utilisée en affiché si
ca ce serait possible oui
Tu verrais ça où ? dans une autorisation ?
- au moment de la validation d'une saisie, si son afficher_si contient une saisie introuvable
c'est plus compliqué, car par ex si tu crée un formulaire formidable avec juste deux saisies, toi, humain peux savoir le nom de la première saisie avant même qu'elle ne soit enregistré, mais pas le vérificateur,
Tu veux dire que ça empêcherait d'utiliser un nom d'une saisie qu'on VA créer après celle qu'on édite ? Oui, ça obligerait à créer la deuxième saisie d'abord.
Mais dans la logique de création d'un formulaire, on conditionne plutôt l'affichage d'une saisie à une saisie précédente (déjà créée), pas suivante (à créer).
Ou bien tu parles de l'étape de création du formulaire, avant de l'enregistrer une première fois ? mais les saisies sont déjà nommées à ce moment là non ?
Et sur le front, ajouter une condition true pour éviter l'erreur ?
pourquoi pas, mais il faut régler aussi en php. Et surtout, c'était le sens de mon propos, il faut d'abord regler cela en terme de prevenir les personnes, ne pas masquer les infos.
Oui, tout à fait.
Ce problème n'apparaissait pas avant la refonte, je crois pas qu'on puisse couper à le régler.
disons que la refonte a defini de manière plus strictre des règles et que des choses qui passaient avant passent plus
A mon avis, prévenir :
- au moment de la suppression d'une saisie, en vérifiant si elle est utilisée en affiché si
ca ce serait possible oui
Tu verrais ça où ? dans une autorisation ?
non, dans la fonction _verifier de formulaire de construction des formulaires (construire_formulaire_verifier())
- au moment de la validation d'une saisie, si son afficher_si contient une saisie introuvable
c'est plus compliqué, car par ex si tu crée un formulaire formidable avec juste deux saisies, toi, humain peux savoir le nom de la première saisie avant même qu'elle ne soit enregistré, mais pas le vérificateur,
Tu veux dire que ça empêcherait d'utiliser un nom d'une saisie qu'on VA créer après celle qu'on édite ? Oui, ça obligerait à créer la deuxième saisie d'abord.
Mais dans la logique de création d'un formulaire, on conditionne plutôt l'affichage d'une saisie à une saisie précédente (déjà créée), pas suivante (à créer).
Ou bien tu parles de l'étape de création du formulaire, avant de l'enregistrer une première fois ? mais les saisies sont déjà nommées à ce moment là non ?
les saisies sont nommées certes, mais comme on traite chaque saisie indépendamment (ce sont des formes différentes), on ne peut pas les passer à la fonction de verif (c'est pour ca que je n'ai pas implémenter de telle fonctio).
En tout cas pas facilement / pas de manière évident. Mais peut être que je dis une carabistouille.
Et sur le front, ajouter une condition true pour éviter l'erreur ?
pourquoi pas, mais il faut régler aussi en php. Et surtout, c'était le sens de mon propos, il faut d'abord regler cela en terme de prevenir les personnes, ne pas masquer les infos.
Oui, tout à fait.
a noter que cette partie "front" se fait assez facilement grace au découpage fonctionnelle du code (expliqué dans l'article sur contrib)
je rebondis sur ce sujet pour signaler une erreur JS qui nous a bien embêtés (pour parler poliment).
On a identifié que si dans le "afficher_si", on a une condition type @input_1@>0, ça génère une erreur dans un eval(condition) car condition vaut : "$(form).find('[name=\"input_1\"]').val() > "
et forcément, ça casse tout le JS.
Si quelqu'un a déjà les mains dans le cambouis ça ne devrait pas être incontournable. Sinon, je peux m'y coller
--
Camille
Donc à priori la compilation remplace les zéros par du vide ? que sur
">" ou sur un "=" aussi, sur d'autres comparaisons ?
Ces réécritures ne seraient elles pas un boulot pour lequel textwheel a montré ses qualités ?
JL
je pense pas. Notamment parce qu'on doit tenir compte de si on a affaire à des entiers ou pas, selon le type de saisie etc. Du coup il faudrait ajouter plein de tests PHP spécifique, et il y aurait plus d'exception que de règle. De toute facon un parseur spécifique avec des tests unitaires spécifiques a été construit. A mon sens il vaut mieux l'améliorer que de tenter une hypothétique migration sur un outil tout aussi hypothétique.
