This PR was merged into the 2.7 branch.
Discussion
----------
[2.7] [Form] fix choice value "false" in ChoiceType
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #17292, #14712, #17789
| License | MIT
| Doc PR | -
- [x] Add tests for choices with `boolean` and `null` values, and with a placeholder
- [x] Fix FQCN in 2.8 tests, see #17759
- [x] Remove `choices_as_values` in 3.0 tests, see #17886
Commits
-------
8f918e5 [Form] refactor `RadioListMapper::mapDataToForm()`
3eac469 [Form] fix choice value "false" in ChoiceType
Choice values must always be strings, but a place was missing the
casting, breaking the comparison of selected choices when the callback
does not return a string.
This PR was merged into the 2.7 branch.
Discussion
----------
[Form] only use PropertyPath if not already callable
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | could be in edge cases
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #15542
| License | MIT
| Doc PR | -
Currently it uses a PropertyPath even when the string is already a callable. But the callable string should have higher priority since that is also the one documented in ChoiceListFactoryInterface.
Commits
-------
470b140 [Form] only use PropertyPath if not already callable
This PR was merged into the 2.7 branch.
Discussion
----------
[Form] Fixed handling of choices passed in choice groups
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | **yes**
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #14915
| License | MIT
| Doc PR | -
I introduced a bug in the 2.7 ChoiceList implementation when choices are passed as groups:
```
$form->add('response', 'choice', array(
'choices' => array(
'Decided' => array($yesObj, $noObj),
'Undecided' => array($maybeObj),
),
// use getName() for the labels
'choice_label' => 'name',
'choices_as_values' => true,
));
```
In this example, since the choices `$yesObj` and `$maybeObj` have the same array index `0`, the same label is displayed for the two options. The problem is that we rely on the keys passed in the "choices" option to identify choices in a choice list (which are, as you see, not guaranteed to be free of duplicates).
This PR changes the new choice list implementation to identify choices by values instead. We already have the guarantee that choices can be identified uniquely by their string values.
This PR should be included in 2.7.2 to fix the regression.
Unfortunately, a few BC breaks in the new implementation are necessary to make this fix:
* The legacy `ChoiceListInterface` was reverted to how it was in 2.6 and does *not* extend the new `ChoiceListInterface` anymore.
* As a consequence, legacy choice lists need to be wrapped into a `LegacyChoiceListAdapter` when they are passed to any place in the framework where a new choice list is expected.
* The new `ChoiceListInterface` has two additional methods `getStructuredValues()` and `getOriginalKeys()` now.
* `ArrayKeyChoiceList::toArrayKey()` was marked as internal.
* `ChoiceListFactoryInterface::createView()` does not accept arrays and Traversables anymore for the `$groupBy` parameter (for simplicity).
@fabpot Where should we document the upgrade path for 2.7.1 => 2.7.2?
Commits
-------
7623dc8 [Form] Fixed handling of choices passed in choice groups
The extension classes are now the only constructor argument of the FormFactory class. They replace the existing "type loader" classes.
new FormFactory(array(
new CoreExtension($validator, $storage),
new CsrfExtension($csrfProvider),
new DoctrineOrmExtension($em),
));
Together with a few upcoming commits this mechanism will make
* extension of the form framework in bundles and
* usage of the forms outside of Symfony2
much easier.
Based on dfb93b1bcebf1f34d3a880d00f36acb2bcca0f08:
[FORM] Fixed DateField Month Choices
The month choices were calculated using the current day of the month with
gmmktime rather than the 1st of the month. Additionally, this provides a
UTC timestamp which is passed to the formatter (IntlDateFormatter) which
converts the timestamp using the current timezone. This means that the UTC
timestamp for 1st March was being converted for my timezone (EST) and giving
a date of 28th February, leading to Feb appearing again in the popup form
instead of Mar.