Skip to content

Explain how to provide custom form options #6527

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from
Closed

Explain how to provide custom form options #6527

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0345790
Explain how to provide custom form options
lewis-spears-flashtalking May 3, 2016
0503805
Fixed option name typo
lewis-spears-flashtalking May 3, 2016
24661b5
Fixed indentation
lewis-spears-flashtalking May 3, 2016
6268f35
Altered the introduction to passing form options
lewis-spears-flashtalking May 3, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions book/forms.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ;)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if, for example, a developer wanted to dynamically set the require options to true/false, how could they go about doing that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

@HeahDude HeahDude May 3, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, I will wait to see what the other team members have to say before creating a pull request for previous version documentations.

around this, you will need to create the default options in the form class ``configureOptions()`` method::

use Symfony\Component\OptionsResolver\OptionsResolver;
use Symfony\Component\Form\Extension\Core\Type\PasswordType;
use Symfony\Component\Form\Extension\Core\Type\TextType;

public function buildForm(FormBuilderInterface $builder, array $options)
{
$builder->add('username', TextType::class, array('required' => $options['username_required']));
$builder->add('password', PasswordType::class, array('required' => $options['password_required']));
}

public function configureOptions(OptionsResolver $resolver)
{
$resolver->setDefaults(array(
'username_required' => true,
'password_required' => false,
));
}

.. index::
single: Forms; Creating form classes

Expand Down