Explain how to provide custom form options #6527
Conversation
The documentation doesn't explain how to pass in form options, so an example was provided.
|
|
||
| public function buildForm(FormBuilderInterface $builder, array $options) | ||
| { | ||
| $builder->add('username', TextType::class, array('required' => $options['username_required'])); |
There was a problem hiding this comment.
In the code samples we use the same rules of Symfony code, so please indent code with 4 white spaces. Thanks!
| @@ -1021,6 +1021,29 @@ to the ``form()`` or the ``form_start()`` helper: | |||
| a PUT, PATCH or DELETE request. Read the cookbook chapter | |||
| ":doc:`/cookbook/routing/method_parameters`" for more information. | |||
|
|
|||
| .. note:: | |||
|
|
|||
| Now that the ``createForm()`` method requires the FQCN, you can not longer pass in ``__construct()`` arguments. To get | |||
There was a problem hiding this comment.
Although passing an option is a good tip to have, you can define a form type as a service, which is documented: http://symfony.com/doc/current/book/forms.html#defining-your-forms-as-services.
I think you could change this introduction, and propose this PR on older branches.
There was a problem hiding this comment.
I agree. I've added a note to prevent people getting confused with Forms as services.
This change was primarily because in previous Symfony version I could pass options such as
public function __construct($password_required = false) {}
into the form constructor which would allow me to alter the option throughout the code base. I can no longer do this in Symfony 2.8+, thus having to pass them as options.
I believe it would be overkill to use the Forms as services in this instance.
There was a problem hiding this comment.
Of courses, what I mean is that passing options through the constructor should not be recommended (only services and parameters should imo), and you should not have to change your code in such case, if you just use the $options array to handle options in the first place ;)
There was a problem hiding this comment.
So if, for example, a developer wanted to dynamically set the require options to true/false, how could they go about doing that?
There was a problem hiding this comment.
I'm confused by your question as the answer is in your tip.
I'm sorry if I wasn't clear, I think that your change for adding such example is a good idea and should go in 2.3, so developers use the $options argument instead of the constructor and don't have to change their form type implementation when upgrading to 3.0 but only to pass a class name instead of an instance.
There was a problem hiding this comment.
Ah, I get what you're saying now! So, should this example be included in previous symfony version documentation too to ensure developers avoid the constructor argument implementation and try to enforce the $options implementation?
There was a problem hiding this comment.
In my humble opinion yes, but please wait for some reviews from the team.
I guess passing options to the constructor is a bad idea, only helper instances or deep shared config should.
Think of a same form type used many times with different options but same dependencies.
If you take a look at the internal types using dependencies, you'll see that only ChoiceType and EntityType use their constructor for the choice factory and loader (btw that's why all the others have been deprecated as services in 3.1).
I'm not sure but I don't think that any internal form types had to be refactored after this BC break.
There was a problem hiding this comment.
I agree, I will wait to see what the other team members have to say before creating a pull request for previous version documentations.
|
This is actually quite an important topic. It's too advanced for a book article though (these articles already contain to much info). This deserves a special section in the cookbook article about custom form types: http://symfony.com/doc/current/cookbook/form/create_custom_field_type.html Do you maybe want to make this change in this PR? (otherwise, just comment and we'll take it over) If you continue this PR, please make sure you indent everything with 4 spaces (both PHP code and reStructured Text syntax) and wrap your lines after the first word that crosses the 72th character. That'll make our lives a bit easier. |
|
ping @lewis-spears-flashtalking :) |
|
Closed because of the conflicts and lack of activity/feedback. Opened an issue to complete this in a future pull request: #9138. |
|
https://symfony.com/doc/2.7/reference/forms/types/collection.html#options Here it is explained, but it is as I understand deprecated. When working on symfony 2.8, it still works, but could not find in 2.8 documentation. I think it should be if it works, because you have to waste time because you do not even think that it can be in older documentation. Just luckily found word deprecated in here https://stackoverflow.com/questions/33343866/option-does-not-exist-error-when-passing-through-option-from-controller-to-embed and so decided to try to check 2.7 docs. |
|
If you use the |
|
Where should see the deprecation message? I did not see. |
|
Your Symfony application should show you this deprecation message. |
The documentation doesn't explain how to pass in form options, so an example was provided.