[Form] Add "is empty callback" to form config #32747
Conversation
There was a problem hiding this comment.
We also need to trigger some deprecations if implementations of the FormConfigInterface and FormConfigBuilderInterface do not implement the new methods. And those changes must be documented in the CHANGELOG.md file of the Form component as well as in the UPGRADE-4.4.md and UPGRADE-5.0.md files.
src/Symfony/Component/Form/Extension/Core/Type/CheckboxType.php
Outdated
Show resolved
Hide resolved
Nice point, let's throw a deprecation in the Is the BC break on |
I was thinking about that as well. Right now I couldn't come up with anything that used to work before and would now break. And our test suite seems to confirm this. But we should try hard to think about potential use cases that could break with this change. |
5c69323 to
601a517
Compare
|
I wonder if it might be useful to add a dedicated option to set it up, maybe an |
|
I was actually rather thinking about whether we should mark the new method as internal instead as I am not really sure that this is an extension point we should expose that much. I think usage of this in userland is quite limited and it increases risk by forms not working correctly if not used correctly. |
src/Symfony/Component/Form/Extension/Core/Type/CheckboxType.php
Outdated
Show resolved
Hide resolved
Using an option would mean that it could not exist (in custom form type not extending
I agree that userland usage is limited. However, I'm against making it internal because it adds a nice customisable behavior if well used. |
src/Symfony/Component/Form/Extension/Core/Type/CheckboxType.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Form/Tests/Extension/Core/Type/ChoiceTypeTest.php
Outdated
Show resolved
Hide resolved
601a517 to
98df4f2
Compare
… (fancyweb) This PR was merged into the 4.3 branch. Discussion ---------- Sync "not implementing the method" deprecations messages | Q | A | ------------- | --- | Branch? | 4.3 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Suggested in #32747 (comment) Useful for consistency and for future reference for similar messages. Commits ------- f6fae1c Sync "not implementing the method" deprecations messages
… (fancyweb) This PR was merged into the 4.3 branch. Discussion ---------- Sync "not implementing the method" deprecations messages | Q | A | ------------- | --- | Branch? | 4.3 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Suggested in symfony/symfony#32747 (comment) Useful for consistency and for future reference for similar messages. Commits ------- f6fae1c361 Sync "not implementing the method" deprecations messages
f4d1c75 to
24e199d
Compare
7c430bd to
899a2b9
Compare
899a2b9 to
32cd54c
Compare
32cd54c to
cc73e52
Compare
cc73e52 to
0226851
Compare
0226851 to
7bfc27e
Compare
|
Comments discussed with @fancyweb on Slack, we can ignore them, PR is good to go. |
|
Thank you @fancyweb. |
This PR was merged into the 5.1-dev branch. Discussion ---------- [Form] Add "is empty callback" to form config | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #31572 for 4.4+ | License | MIT | Doc PR | - This PR introduces a new feature that allow to resolve a bug. Currently, the `isEmpty()` behavior of the `Form` class is the same whatever its configuration. That prevents us to specify a different behavior by form type. But I think that some form types should have dedicated empty values. For example, the `CheckboxType` model data either resolves to `true` (checked) or `false` (unchecked). But `false` is not an empty value in the `Form::isEmpty()` method, so a `CheckboxType` form can never be empty. `false` should not be in that list because for other form types, it's perfectly fine that it's not considered as an empty value. The problem is better seen in #31572 with a `ChoiceType` that is never considered as empty (when no radio button is checked). Being able to specify the "is empty" behavior by form type would also allow users to define their own logic in their custom form types + probably define it ourselves in all our form types in order to get rid of the default common behavior. Commits ------- 7bfc27e [Form] Add "is empty callback" to form config
…ncyweb) This PR was merged into the 3.4 branch. Discussion ---------- [Form] Handle false as empty value on expanded choices | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | #31572 | License | MIT | Doc PR | - This is the 3.4 version of #32747. The tests are the same. The added code has to be removed from master (if accepted). Commits ------- 1a366bc [Form] Handle false as empty value on expanded choices
This PR introduces a new feature that allow to resolve a bug.
Currently, the
isEmpty()behavior of theFormclass is the same whatever its configuration. That prevents us to specify a different behavior by form type.But I think that some form types should have dedicated empty values. For example, the
CheckboxTypemodel data either resolves totrue(checked) orfalse(unchecked). Butfalseis not an empty value in theForm::isEmpty()method, so aCheckboxTypeform can never be empty.falseshould not be in that list because for other form types, it's perfectly fine that it's not considered as an empty value.The problem is better seen in #31572 with a
ChoiceTypethat is never considered as empty (when no radio button is checked).Being able to specify the "is empty" behavior by form type would also allow users to define their own logic in their custom form types + probably define it ourselves in all our form types in order to get rid of the default common behavior.