Discussion :

[mantex]

Bonjour,

J' ai un ptit soucis avec un formulaire (1 fois de plus.. ) qui a besoin de vérifier l' unicité d' un champs (email) en même temps que son format.

J' ai mis une contrainte d' intégrité sur le schéma, mais je n' arrive pas à sortir proprement une erreur sur ce champs.

Au départ j' utilisé sfValidatorDoctrineUnique comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 'email_address' => new sfValidatorDoctrineUnique(array('model' => 'Customer', 'column' => 'email_address'), array( 'invalid' => 'Cette adresse e-mail est déjà dans la base client')),

Super pour la création de nouveau enregistrement, mais à l' update impossible de valider le formulaire si on ne change pas le champs.


Alors on ma conseillé ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
$this->validatorSchema->setPostValidator(
      new sfValidatorAnd(array(
        new sfValidatorDoctrineUnique(array('model' => 'Customer', 'column' => array('email_address','id')), array('invalid'=>'Cette adresse e-mail est déjà dans la base client')),
)));

Qui ne marche pas. => erreur d' intégrité..

Si quelqu' un à une lumière pour m' éclairer.

[Michel Rotta]

Ta première validation est presque la bonne, en fait tu devrais mettre un sfValidatorAnd() dans la validation du champs pour pouvoir y effectuer les deux vérifications, unicité et adresse email valide.

Je ne comprend pas ton problème lors de l'édition d'un enregistrement. Tu dis : "à l' update impossible de valider le formulaire si on ne change pas le champs" comment cela ce manifeste-t-il ?

Dans ta deuxième syntaxe tu utilises un sfValidatorAnd() dans le post validator avec un seul argument dans le tableau, dans ce cas, le sfValidtorAnd() n'a aucun intérêt. Contrairement à ce que beaucoup de personnes imagine on peut parfaitement exécuter un post validator sans lui adjoindre un sfValidatorAnd().

Le post validator permet de vérifier une (ou plusieurs) conditions après que les conditions individuelles aient été validées. C'est généralement des conditions qui portent sur plusieurs champs simultanément, ce qui n'est pas ton cas ici. Il y a peu d'intérêt à le faire pour des validations qui portent sur un champ unique.

[mantex]

Avec la première méthode:

La création se passe bien et l' unicité est vérifié.

Par contre je ne peux pas update un enregistrement car le formulaire refuse de se valider du fait que l' adresse email est déjà dans la base forcément.

Avec la deuxième méthode:

j' ' obtiens une page blanche lorsque rien ne fonctionne sur la vérif d' unicité.

Mon formulaire ne devrait donc pas être validé et m' afficher une jolie erreur du type "Cette email est deja pris" dans les deux cas create & update.

Avec la première méthode j' obtiens la moitié de cet objectif mais qui est bloquant pour le client.

[Michel Rotta]

Effectivement, le validateur est conçu pour être uniquement utilisé en création.

Si tu veux que l'adresse de messagerie soit unique, il faut alors utiliser une approche différente.

Un traitement à la création avec saisie de l'adresse, un traitement à l'édition avec un affichage de l'adresse.

Éventuellement un traitement pour changer d'adresse (et que d'adresse) qui sera forcément différente de toutes les adresses présente, y compris de celle en cause.

Si non il faudrait pouvoir créer un validateur unique qui aurait connaissance de l'adresse préalable et ne validerait que si elle à été modifiée. Mais je ne vois pas du tout comment lui communiquer l'adresse préalable. C'est peut-être possible, en effet, le validateur est initialisé avant le bind (a vérifier) et après la création. Donc l'objet de modèle est lié avec les anciennes valeur à la création, donc à l'initialisation du form. On doit pouvoir fournir au validateur l'adresse actuel de l'objet du modèle, et lors de la vérification savoir si elle a été modifiée. A tester (un peu lourd, mais on doit pouvoir se baser sur un validateur enfant du validateur email, avec un paramètre de plus).

[mantex]

Ben a quoi il sert alors si il fait le job à moitié.

Encore une fois ce type de cas est très courant. Si on vérifie l' unicité c 'est pas une fois de temps en temps le jeudi quand il fait beau.

Pour être plus sérieux:
le plus simple serait de pouvoir désactiver le validateur sur certaines actions comme l' update par exemple.

Par ce que dans mon cas, non seulement le job n' est pas fait jusqu' au bout mais l' utilisateur se trouve bloquer.

C 'est ce qui pourrai s 'appeler un effet contre-productif pour un outil qui me laisse de plus en plus perplexe.

[Michel Rotta]

Je n'ai pas d'autre réponse que celle déjà apportée.

Mais symfony est un framework très ouvert, il est parfaitement possible d'écrire ton propre validator et de trouver une solution pour distinguer l'édition de la création.

Quant à le désactiver suivant que l'on est en création où en édition, c'est assez simple à faire. Il est possible de créer deux méthodes dans son form qui active l'un ou l'autre validateur et, une fois l'objet créé dans le contrôleur, d'appeler la méthode interne pour mettre les validateurs spécifique en place.

Mais c'est courir le risque qu'une modification tombe sur une adresse déjà existante et ne génère une erreur... Et connaissant Murphy...