-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Form] Rename "empty_data" to "data_factory" #5939
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.
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
Comments
An alternative name for this option is "create_data" or "new_data": $options = array(
'new_data' => function (FormInterface $form, $data) {
return new User($data['username']);
}
);
$form = $factory->createBuilder('form', $options)
->add('username', 'text', array('mapped' => false))
->add('password', 'password')
->getForm(); |
@bschussek would |
@dlsniper Should the data mapping ever be outsourced into a serializer as proposed in #5480, this option would move to that serializer as well. |
👍 with this rename. What about |
I was also setting |
I like |
|
Other idea that came up in the comments to William's blog post: |
+1 for |
I'm also +1 for Any chance to see this change merged in 2.7? :) |
I agree that changing the name has a cost that does not worth it IMHO. This option is confusing by design, and I hope the latest change in the docs will help with that, even if we can still enhance some stuff there. 👍 for closing here though. |
I agree with @vudaltsov and @HeahDude |
The current option "empty_data" is easily misunderstood (see #4715 and #5906). While the option would intuitively set the data that is returned from the field if the field is empty, it in fact sets the view data used if the field is empty, which is then transformed back to model format. So, like mentioned in #5906, setting "empty_data" to an empty string will not lead to the field returning an empty string, because empty strings are transformed to
null
by default.The major use case for "empty_data" is thus to create objects that fields can be mapped into.
Example 1:
Example 2:
Consequently, I propose to deprecate "empty_data" and rename it to something more intuitive, like "data_constructor":
We can probably also deprecate the option to pass objects directly to the option instead of closures (see Example 1). IMO objects should be created on demand, not precautiously.
Once the deprecation phase is over (2.3) we can reintroduce "empty_data" with a new meaning and fix #4715 and #5906.
The text was updated successfully, but these errors were encountered: