Discussion :

[basket]

Bon, je ne vous suis pas tout à fait car on s'écarte de mes compétences (stacker, closures ??) mais peu importe après tout, je vous laisse continuer et je prends ce que je comprends, pour le reste je posera les questions en temps voulu. En passant, je retiens le "new ArrayObject()".

La validation technique ou fonctionnelle d'un formulaire champ par champ, pas de soucis. A chaque champ son validateur - technico-fonctionnel, peu importe - et le résultat de la validation du formulaire est la la "somme" des validations unitaires de chacun des champs.

Comment faire lorsqu'on a une validation fonctionnelle qui lie deux champs ? par exemple lorsqu'on demande à un utilisateur de saisir 2 fois son email à la création de l'utilisateur pour vérifier qu'il n'y a pas d'erreur ?

C'est un validateur d'un autre ordre, non ? puisqu'il s'applique à deux champs à la fois.
Qu'en pensez-vous ?

Merci pour vos éclaircissements.

[Benjamin Delespierre]

Tiens ça c'est pas mal, j'avoue que je n'y avais pas pensé.

La solution la plus simple serait de faire en sorte que les validateurs se voient passés une instance de l'objet Request (ou registre, je ne sais pas quel formalisme vous utilisez.) Ils pourraient alors valider un champ en fonction du contexte de la requête, en l'occurence l'identité avec un autre champ.

Ça se traduit par un paramètre supplémentaire dans la méthode validate des validateurs de champ.

[jonoz]

Bon, je ne vous suis pas tout à fait car on s'écarte de mes compétences (stacker, closures ??) mais peu importe après tout, je vous laisse continuer et je prends ce que je comprends, pour le reste je posera les questions en temps voulu. En passant, je retiens le "new ArrayObject()".

La validation technique ou fonctionnelle d'un formulaire champ par champ, pas de soucis. A chaque champ son validateur - technico-fonctionnel, peu importe - et le résultat de la validation du formulaire est la la "somme" des validations unitaires de chacun des champs.

Comment faire lorsqu'on a une validation fonctionnelle qui lie deux champs ? par exemple lorsqu'on demande à un utilisateur de saisir 2 fois son email à la création de l'utilisateur pour vérifier qu'il n'y a pas d'erreur ?

C'est un validateur d'un autre ordre, non ? puisqu'il s'applique à deux champs à la fois.
Qu'en pensez-vous ?

Merci pour vos éclaircissements.

En fait, ton champ de confirmation de mot de passe n'a pas de valeur métier (= il n'est en général pas persisté donc ne figure pas dans le modèle).

Son existence ne se justifie que pour des raisons "techniques". Qu'est-ce qui nous empêche de dire que FormFieldPassword n'aura pas deux attributs mdp et confirmation mdp ? Le vrai objet métier c'est User, UserForm et ses validators sont des objets "techniques"

Du coup tu peux dériver FormField en FormFieldPassword qui aura ces deux attributs et soit écrire un Validator qui vérifie l'égalité de deux valeurs si tu utilises la méthode qui consiste à empiler (stacker) des validators multiples pour effectuer ta validation, soit tester que les valeurs des deux propriétés sont identiques. Il faut juste essayer de s'abstraire de la vue, qui elle comportera deux champs.

Si vraiment tu veux deux FormFields, alors une solution est de créer un Validator de comparaison injecté dans UserForm, et appelé dans la méthode isValid() de UserForm en plus du traitement de validation de chaque champ individuellement. Dans mon exemple, je n'ai montré que de la validation champ par champ, ça ne veut pas dire que l'on proscrit la validation générale au niveau du Form. Un autre exemple qui ne marche pas en champ par champ est la validation conditionnelle : si tel checkbox est checkée, alors telle autre champ doit obligatoirement être rempli.

Du coup, c'est une solution extrêmement simple, qui laisse le modèle cohérent.


Pour ta question Benjamin, je ne me suis pas trop penché sur la question mais sans trop réfléchir, j'aurais tendance à manipuler des sessions (ou toute autre couche d'abstraction de session), associées à de la sérialisation. Tu peux te représenter une session comme une couche de persistance en fait et y stocker des variables itérables. Les deux problèmes : la sécurité des sessions et la mise à jour des données (en gros, quand mettre à jour les données cachées). Je t'avoue que l'intérêt pratique me semble relativement faible et qu'il faut du coup résoudre les problèmes classiques d'un eager loading.

Ce qui est sûr, c'est qu'un registry ne nous aide pas.

Je vais réfléchir à ton idée et revenir vers toi en MP afin de ne pas trop transformer le thread en fourre-tout.

[basket]

Merci merci.

J'ai travaillé sur le sujet. Ce fut un peu laborieux mais j'y suis arrivé je crois. Voici mon retour d'expérience :

Je me suis créé quelques validateurs de champ génériques que j'utilise pour la validation des champs :
- vérifier que la valeur du champ est renseigné (pour les champs obligatoires - les autres validateurs ne renvoient pas d'erreur si le ou les champs sont vides)
- vérifier que la valeur du champ est un email
- vérifier que la valeur du champ est un entier
- vérifier que la valeur du champ est un nombre compris entre deux valeurs (si une seule borne est renseignée, alors seule cette borne est testée)
- vérifier que la valeur du champ est dans une liste de valeurs
- vérifier que la valeur du champ est d'une taille comprise entre deux longueurs (si une seule borne est renseignée, seule cette borne est testée)

J'ai modifié les interfaces IField et IForm pour que les champs et formulaires acceptent plusieurs validateurs (il n'y a plus de setValidator() mais que des addValidator().

Mes classes Form et Field ne sont plus abstraites car je n'ai pas forcément besoin d'instancier un objet d'une classe étendue pour rien, je préfère instancier directement l'objet de la classe générique.

J'ai créé des validateurs de formulaires génériques
- vérifier que 2 champs ont des valeurs égales
- vérifier que 2 champs ont des valeurs différentes
Je passe à ces validateurs des instances de la classe Field (instances que j'ai instanciées en amont pour les valider unitairement).

Les autres validateurs de formulaires sont des validateurs beaucoup plus spécifiques qui vérifient par exemple qu'à la création d'un nouveau compte qu'un login n'existe pas déjà dans la base. J'avoue que je ne suis pas certain de la bonne pratique (est-ce bien ici qu'il faut le faire), mais c'est ce que j'ai trouvé pour gérer les messages aux utilisateurs de manière cohérente.

Tout n'est pas fini car j'ai plein de formulaires à gérer.


Et bien sûr, si je comprends comment utiliser tout ça ici, il me reste encore, sur un nouveau sujet, à réussir à comprendre que mon besoin peut se résoudre avec une interface et à la concevoir proprement !!


A bientôt

[Benjamin Delespierre]

Juste pour ajouter mon grain de sel, s'il y a une méthode "valid" dans Iterator, c'est pour qu'on s'en serve. C'est pour ça que j'ai émis l'idée de valider tes champs de formulaire avec des itérateurs

En dehors de ça, tu es sur le bon chemin visiblement. Tu n'as plus qu'a industrialiser un peu le processus et c'est dans la poche.