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
