[sf 1.4.x] sfValidatorDoctrineUnique sur update formulaire

[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 :

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 :

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...

[mantex]

et tu as un exemple sachant que je ne touche pas au form (template auto généré).

Peux t on faire le test dans la fonction configure() ?

merci d' avance.

[Michel Rotta]

Sur ce type de cas je n'ai pas de d'exemple, mais n'importe quel widget peut servir d'exemple, c'est ainsi que j'ai découpé ces objets. La seul difficulté est de récupérer les informations sur l'utilisateur courant.

On peut faire ce que l'on veut dans la méthode configure. La question est de savoir si on aura les informations permettant de tester. La fonction configure est exécutée lors de l'initialisation de l'objet. Il me semblerait préférable de créer une méthode supplémentaire en charge de modifier la configuration de l'objet et qui pourra être lancée depuis le contrôleur. Ce qui impliquerait de modifier le contrôleur de l'auto-généré, ce qui est prévu dans l'architecture sans perte des avantages de l'auto-généré.

[mantex]

Tu n' as donc pas eu à gérer ce cas ? Tu as bien de la chance alors..

Je ne comprends pourquoi des cas aussi simple nécessite une complexité pareil.

Si je dois passer plus de temps pour comprendre/faire des choses simples avec un outils qui est censé me faire gagner du temps sur des choses simples (ce constat est déjà absurde en soit)

Autant faire les choses moi même au moins j' essaierai de ne pas faire la moitié des choses que je promets.

Désolé, je suis plutôt patient et persévérant en temps normal mais la, j' avoue qu' autant de contradictions me désespère un peu.

Dommage ce framework semblait prometteur, trop peut être..

Mais un framework ou il faut en permanence allez dans le code pour ajouter des fonctions de bases ne devrait pas être en production, je vois cela comme du développement collaboratif assez peu exploitable dans une réalité ou le client va avoir du mal à payer des choses évidentes.

[Michel Rotta]

Symfony présente l'avantage d'être très personnalisable et parfaitement extensible. Et ce très simplement la majeur partie du temps.

Imaginer que tes besoins unique et personnel sont des besoins courants qui devraient être pris en compte au détriment d'autre problèmes plus généraux ne me semble pas correcte comme réflexion.

Écrire un validateur a partir d'un existant n'est pas quelque chose de compliqué. Sauf le tient. Et encore.

Tu as aussi la possibilité d’appeler une fonction externe avec callback.

La bonne solution, et qui en plus marche avec le validateur, me semble bien de ne pas permettre la modification d'une information pertinente et unique. Et, le cas échéant, à en déporter la modification dans un formulaire indépendant.

Maintenant, si cette donnée doit être régulièrement modifiée et malgré tout rester unique, il faudra en passer par un validateur adapté.

En deux ans d'activité sur ce forum je n'ai jamais vu passer ce type de besoin, ce qui relativise la portée générique de la question.

[mantex]

Comme beaucoup je pense, l' utilisation d' un Framework est de se baser sur un "cadre de travail" pour ne pas avoir entre autre à reinventer la roue.

Comme beaucoup, Je ne cherche pas inventer des nouveaux concepts ou réecrire une partie du code de firefox.

Non juste réaliser des choses simples que mes clients demandent en re utilisant des principes vues et revues en gardant une bonne visibilité de ce qui est fait. Tout cela dans le but de gagner du temps pour le projet en cours et ceux à venir.

Les fonctions CRUD sont d' ailleurs un exemple concret.

Je ne pense pas que créer ou "editer un profil" utilisateur sans vérifier que son adresse e-mail soit déjà utilisé d' ailleurs soit très rare.

Cela pourrai être d' ailleurs très bien le champs login.

Quel site ne propose pas aujourd'hui' hui l' édition de son profil ?

Si je ne pas mettre à jour mon profil quelque que soit le champs juste parce mon adresse e-mail est vérifié alors je ne l' ai d' ailleurs pas modifié.

Pire: Si des formulaires crud sont auto-générés c ' est bien pour les utiliser ?

Dans le cas contraire ce type d' outils ne me sert à rien.

Autant construire les formulaires à la main avec son propre code, au moins si il y a un bug évident on va pas chercher 3 jours juste pour trouver la cause problème.



Si tout est exception, cela fini par plus être exploitable .

je suis pragmatique:

Si 10 copier/collé de code compréhensibles,simples, et modifiables, me fait gagné plus de temps, plus de souplesse que 5 lignes non explicite et m' obligeant à remettre en cause des choses simples.

Alors oui je dois bien avoué que le choix est vite fait.

La théorie c' est bien mais faut il que cela soit réalisable dans un projet concret je parle pas de projet type cas d' école.