[Form] ChoiceType: Fix a notice when 'choices' normalizer is replaced #17406
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Can you please add a test to avoid regressions? |
|
@xabbuh I added a test, which covers this special case and also modified the PR comment a little bit. |
|
Thank you @paradajozsef. |
fabpot
added a commit
that referenced
this pull request
Jan 19, 2016
…is replaced (paradajozsef) This PR was squashed before being merged into the 2.7 branch (closes #17406). Discussion ---------- [Form] ChoiceType: Fix a notice when 'choices' normalizer is replaced | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #17270 | License | MIT | Doc PR | - As @gseidel [mentioned](#17270 (comment)), the notice only occurs, when a custom choice field added after a choice field **and** the custom type is expanded, **and** the ```'choices'``` normalizer is replaced. The problem is that when ```'choices'``` option is replaced, the [default choiceNormalizer](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php#L262) is not invoked. This normalizer would [clear](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php#L264) the labels from previous invocation, but it's been replaced in the custom choice type. As a result [$choiceLabel](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php#L279) normalizer will get the wrong labels because it shares the same scope with [$choiceNormalizer](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php#L262). Resetting the label values after copy solves this problem. Commits ------- be056fd [Form] ChoiceType: Fix a notice when 'choices' normalizer is replaced
fabpot
added a commit
that referenced
this pull request
Jan 21, 2016
This PR was merged into the 3.1-dev branch. Discussion ---------- [Form] Make tests compatible with master | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - I wrote tests in this PR: #17406 which was compatible only with 2.7. @xabbuh fixed it in 2.8 and 3.0 here: #17463. And this PR fixes deprecated notices in master. Kind of an unfortunate situation... Commits ------- 96e40b2 Fix unit tests in master
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As @gseidel mentioned, the notice only occurs, when a custom choice field added after a choice field and the custom type is expanded, and the
'choices'normalizer is replaced. The problem is that when'choices'option is replaced, the default choiceNormalizer is not invoked. This normalizer would clear the labels from previous invocation, but it's been replaced in the custom choice type. As a result $choiceLabel normalizer will get the wrong labels because it shares the same scope with $choiceNormalizer. Resetting the label values after copy solves this problem.