Changer option formulaire

Bonjour

je voulais juste s'avoir comment changer une option d'un champ sur SF2 d'un formulaire hériter. j'ai bien trouver une solution mais je la trouve "pas super"
J'aurais aimer faire

Code:

---

$optionsUsername = $builder->get('username')->setOption('label','Utilisateur');

---

Mais me voila avec cette immonde code:

Code:

---

1 2 3 4

$optionsUsername = $builder->get('username')->getOptions(); $typeUsername = $builder->get('username')->getName(); $optionsUsername['label'] = 'Utilisateur'; $builder->add('username', $typeUsername, $optionsUsername);

---

(pourquoi faire simple quand ont peux faire compliquer ?)

Soit je loupe un truc avec SF2 soit SF2 a oublier d’implémenter une pitit méthode de 3 ligne :-) Donc si ma solution est la bonne j'aimerais comprendre pourquoi Mr Potencier à décider de coder des truc pareil

Merci pour votre aide

Hello,

M. Potencier n'a pas oublié de faire trois lignes, par contre, toi, tu as certainement zappé un paquet de lignes de la documentation.
La méthode add de ton builder prend trois paramètres : le nom de ton champs, son type, et un tableau d'options.

La construction de ton FormType devrait d'avantage ressembler à quelque chose dans ce gout là :

Code:

---

1 2 3 4

$builder->add('username', 'text', array( 'label' => 'Utilisateur', ));

---

Je t'invite à regarder un peu quelques options qu'il est possible de passer => http://symfony.com/fr/doc/current/re...ypes/form.html

Sinon tu peux toujours lui faire une PR, ça le fera bien rire :)

Je ne parle pas d'ajouter un champ ... ta reponse confirme ma crainte (ajout au lieu de modif ou tou ajoute rpour ecraser lancien)
Je veux ajouter une option a un champ déja existent et definie dans la class Type parent de la façon la plus DRY possible donc surement pas en réutilisent Add qui demande de nouveau le type et les option déjà passer.

Je n'avais pas fais attention à la notion d'héritage.

Je ne vois pas d'autre solution que celle que tu donnes qui revient globalement au même que la mienne, à ceci près que pour de ne pas te répéter tu perds en clarté en séparant la config surchargée et la config de base dans deux fichiers séparés.

Si tu jètes un œil aux classes FormBuilder et FormConfigBuilder, tu verras qu'il n'y a aucune méthode qui "édite" les options.

Et c'est normal : la notion de FormBuilder fait que lorsque tu crées ton formulaire, tu peux surcharger un champs tout entier (le champs username), mais pas surcharger le tableau de configuration qui permet de le construire. Parce qu'en faisant ça, tu ne répercutes pas les changements sur le reste du form, tu as juste changé la config, mais tu n'as pas reconstruit ton élément à partir de la nouvelle config.

C'est comme si tu changeais les fichiers config et parameters sans réinitialiser le cache. La config a changé mais pas les éléments que tu utilises.

Bonjour,

S'il s'agit de changer le label du formulaire de FOSUSerBundle, Il sera bien plus simple de travailler au niveau des fichiers de traduction.
http://symfony.com/doc/current/cookb...l#translations

ou bien de travailler au niveau du rendu twig

Je n'aime pas me servir d'un fichier de traduction quand le site n'en a pas besoin . si je personnalise le label dans le twig je ne pourrais plus utiliser {{ form_widget(form) }} et je galérerais avec l'ordre des champs a moins de tous les écrires. Mais la methode twig semble la plus propre sur tous que le label à sa place dans la vue.

Dommage pour le setOption.

Citation:

---

Envoyé par Prestigej

si je personnalise le label dans le twig je ne pourrais plus utiliser {{ form_widget(form) }} et je galérerais avec l'ordre des champs a moins de tous les écrires.

---

Pas d'accord. Le form theming est fait pour ça. Tu peux surcharger le theme du rendu du widget du champs concerné dans ta template sans avoir à tout réécrire. Ensuite tu peux utiliser ton form_widget(form) classique.

http://symfony.com/fr/doc/current/co...amp-individuel