Version imprimable
Bonjour,
Je voulais savoir si c'est normal que l'on rentre dans le "setPostValidator" même si les "validators" des champs ne sont pas bon.
En gros est il possible de rentrer dans le "setPostValidator" seulement si tous les champs sont ok ?
Ou alors est il possible de tester dans le "setPostValidator" si le form est valide ou non.
Merci d'avance
Dans le déroulement d'un form, il est prévu de tester tous les validateurs avant de renvoyer le formulaire à l'utilisateur.
Je ne connais pas de manière simple de ne pas tous les valider.
Vu qu'ils sont déclaré dans des collections, il n'est pas possible de jouer au niveau de configure (ou setup) pour mettre un code conditionnelle qui sera exécuté avant les premiers réels tests de validation.
La seul possibilité éventuelle que je vois serait de créer un validateur dans l'idée du sfValidatorAnd et de conditionner l'exécution des validateurs inclus à ce que l'objet parent (le form) soit ou non valide. La où j'ai des doutes, c'est sur la possibilité de connaître facilement l'état de la validation d'un formulaire depuis un validateur... A voir...
Merci pour la réponse
Ce qui est gênant ici c'est que pour un même champ je vais avoir 2 messages d'erreurs :
1/ celui de mon validateur classique
2/ celui de mon postvalidateur
S'il s'agit de deux erreurs différentes, je ne vois pas où est le problème, c'est des choses qui arrivent régulièrement.
De plus dans le postValidator je fait appel à un webervice. Donc même si le champ est incorrect je fais cet appel.
Dans ce cas je dois donc doubler ma vérification ou alors je dois supprimer le premier validator
Tu vérifies deux choses différentes, ce qui peut entraîner deux messages d'erreur.
Si l'utilisateur se trompe, il voit les deux messages d'erreur et sait qu'il a deux contraintes à vérifier. Dans le cas contraire, le risque est qu'il corrige la première contrainte avant d'avoir une deuxième erreur et donc une deuxième modification à mettre en œuvre. Personnellement, c'est le genre de truc qui me fait quitter un site. Deux, si je suis de bonne humeur, cela va, trois emboitées les unes dans les autres, je me tires... Mais je suis un mauvais client.
Par contre, l’inconvénient est l'appel au web service qui peut être gourmand. Mais d'un autre côté, pour valider le form, même si l'erreur est sur un autre champ, tu feras appel au web service à tous les coups...
Question, ton postValidateur ne porte que sur un champ ? Si oui, quel est l'intérêt de le mettre en postValidateur ? Pourquoi ne pas faire un sfValidatorAnd dans le validateur du champ ?
En effet je n'ai pas besoin d'un postvalidator dans mon cas :P
Merci
ps : Ce qui reste dommage pour moi avec les postvalidator c'est qu'ils sont appelé même si le form est invalide. Car si on utilise des traitements lourds (ws ou autre ...), on les appels un peu dans le vent
Serte,
Mais les post validateurs ne sont pas créé pour permettre un traitement lourd, il sont créé pour permettre de valider des données qui impliquent plusieurs champs (mot de passe et vérification, date début et date fin).
Pour cela ils sont idéal et créé pour.
Il n'est pas simple de contraindre une fonctionnalité à faire quelque chose pour lequel elle n'a pas été conçue.
Après, l'idéal serait de créer un postValidation qui s'intégrerait après la postValidation, si la validation est viable. Ceci revient à modifier le code du sfFormWeb et à le dupliquer entièrement. Ce qui n'est pas idéal en cas de modification de l'objet dans une version future mais ne devrait pas poser beaucoup de problème quant à la mise en oeuvre. Enfin, vu de loin, je n'ai pas démonté le code non plus !