Notice that the same change is present in populateValues, but the test for it is still missing.
The original problem was that prepare() was changing the $name of the nested form elements and then bindValues() could not match that name with the passed $values. This was a bug in release-2.9.2.
This is fixed in the current branch because the name is retrieved differently, but imho the naming is a bit misleading as $element->getName() is indeed a tempting getter to get the element $name. Hence this test imho is needed to be sure the bug does not slip in again.
This test ensures that #83 is fixed, does not happen again and closes #83.
Notice that testCanProperlyPrepareNestedFieldsets() is passed in release-2.9.2, because it is the binding that fails after the "improper" prepare.
weierophinney
commented
5 years ago
This is a test for #83.
The test fails against tags/release-2.9.2 but is successful against current master.
This is due to the change in Fieldset.php from: https://github.com/zendframework/zend-form/blob/2d076100e4c6a779b7676d098192e3d1cf74f34e/src/Fieldset.php#L571 to: https://github.com/zendframework/zend-form/blob/4419eef6dbe9d276e7e27c6a25f022be74534959/src/Fieldset.php#L572
Notice that the same change is present in populateValues, but the test for it is still missing.
The original problem was that prepare() was changing the $name of the nested form elements and then bindValues() could not match that name with the passed $values. This was a bug in release-2.9.2.
This is fixed in the current branch because the name is retrieved differently, but imho the naming is a bit misleading as $element->getName() is indeed a tempting getter to get the element $name. Hence this test imho is needed to be sure the bug does not slip in again.
This test ensures that #83 is fixed, does not happen again and closes #83.
Notice that testCanProperlyPrepareNestedFieldsets() is passed in release-2.9.2, because it is the binding that fails after the "improper" prepare.