Discussion :

[exotux]

Bonjour,

J'utilise les FormEvents (Symfony 2.4) pour gérer l'état de certains champs de mon formulaire en fonction des données de l'utilisateur.

En gros :

• si la checkbox est cochée, un champ doit être désactivé
• si la checkbox n'est pas cochée, un champ doit être activé
• lors de la soumission du formulaire, on revient sur la page du formulaire avec les données à jour.
• l'activation / désactivation des champs est gérer en JS sur la vue lors de l'édition du formulaire par l'utilisateur

Voici le code du formulaire qui fonctionne pour gérer ça : https://gist.github.com/exotux/8556377

La question est : est-ce une bonne méthode ou je suis parti dans un truc trop compliqué ?

Merci

[exotux]

Bonjour,

J'ai nettement simplifier le code :
https://gist.github.com/exotux/8556377

Personne n'a d'avis sur la méthode ?

Merci

[exotux]

Pour éviter la "Fraude", activation du champ désactivé par l'utilisateur j'ai ajouté un event pour m'assurer des données saisies :

https://gist.github.com/exotux/8575657

[gototog]

J'ai pas spécialement le temps de le tester, le code a l'air propre, même si je ne comprend pas forcément le disabled => disabled.
Je me demande si ce n'est pas plus propre de supprimé le champs plutot que de le disabled, ne serait-ce car un petit malin peut enlever le disabled de ton champs formulaire avec firebug par exemple.
De cette manière, pas besoin de revérifier les données coté contrôleur

[exotux]

Merci de ce retour. Je n'ai pas fait une usine à gaz donc.

Pour le disabled => disabled c'est une erreur (mais qui marche). J'ai mis à jour par disabled => true. C'est pour ajouter un attribut disabled sur le champ si la case est cochée.

J'aurai préféré désactiver le champ sur le formbuilder, mais comme il est réactivable en JS via la case à cocher, c'était un peu compliqué : si le champ est désactiver sur le formbuilder, il ne transmet aucune donnée. C'est pour ça que j'ai ajouté le FormEvent::SUBMIT pour contrer un petit malin avec firebug.

Merci