Bug #66533
closedPaths not possible if array used as form object
100%
Description
AbsractFormFieldViewHelper: line 191 (TYPO3 7.1)
protected function getPropertyValue() {
if (!$this->viewHelperVariableContainer->exists(\TYPO3\CMS\Fluid\ViewHelpers\FormViewHelper::class, 'formObject')) {
return NULL;
}
$formObject = $this->viewHelperVariableContainer->get(\TYPO3\CMS\Fluid\ViewHelpers\FormViewHelper::class, 'formObject');
$propertyName = $this->arguments['property'];
if (is_array($formObject)) {
return isset($formObject[$propertyName]) ? $formObject[$propertyName] : NULL;
}
return ObjectAccess::getPropertyPath($formObject, $propertyName);
}
It is not possible to use an array as filter-object in an f:form context with a little bit more complex structures.
I have a 2-dimensional multiple select and want to use an array as filter object but fluid cant determine the value because only one level is checked to retreive the selected value (see above)
If you simple delete the if condition it works, the ObjectAccess::getPropertyPath Utilityfunction is able to work with multi-dimensional arrays, so for what doing this check? It only limits the possibilities.
I think i reported the same isse some time past, so maybe this exists in the fluid package itself and got backported again? But i dont know for sure...
Updated by Benni Mack over 9 years ago
- Target version changed from 7.2 (Frontend) to 7.4 (Backend)
Updated by Susanne Moog over 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Benni Mack about 9 years ago
- Target version changed from 7.5 to 7 LTS
Updated by Claus Due about 9 years ago
Afaics there would be three main suspects as reasons for this check:
- The use case of multidimensional arrays was never considerd
- Performance optimisation because getPropertyPath is considered slow
- Support for accessing original request parameters
I'm pretty sure that 1, maybe 2 is the reason. In any case there's no technical reason why we shouldn't just use getPropertyPath directly and avoid this check - that method is only marginally slower than doing this check and supports more use cases. And it's not like you will face use cases with hundreds of thousands of form fields (which is what it would take to have a noticable effect in rendering time).
Updated by Gerrit Code Review about 9 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44137
Updated by Gerrit Code Review about 9 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44137
Updated by Gerrit Code Review about 9 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/44137
Updated by Gerrit Code Review about 9 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/44137
Updated by Anonymous about 9 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset bee5a1d7dcaa10cd14e05eec5ecc78654ab0b4f0.
Updated by Riccardo De Contardi about 7 years ago
- Status changed from Resolved to Closed