Bug #66533

Paths not possible if array used as form object

Added by Philipp Wrann almost 5 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Fluid
Target version:
Start date:
2015-04-22
Due date:
% Done:

100%

TYPO3 Version:
7
PHP Version:
5.5
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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...

Associated revisions

Revision bee5a1d7 (diff)
Added by Claus Due over 4 years ago

[TASK] Avoid redundant condition blocking arrays as form object

Values of arrays (if formObject) can now be accessed with
property paths e.g. "key1.vars.special"

Change-Id: I578d2ca2d0c5cc5a5ba965e9b7209e88f4af3a88
Resolves: #66533
Releases: master
Reviewed-on: https://review.typo3.org/44137
Reviewed-by: Oliver Eglseder <>
Tested-by: Oliver Eglseder <>
Reviewed-by: Andreas Fernandez <>
Tested-by: Andreas Fernandez <>

History

#1 Updated by Benni Mack almost 5 years ago

  • Target version changed from 7.2 (Frontend) to 7.4 (Backend)

#2 Updated by Susanne Moog over 4 years ago

  • Target version changed from 7.4 (Backend) to 7.5

#3 Updated by Benni Mack over 4 years ago

  • Target version changed from 7.5 to 7 LTS

#4 Updated by Claus Due over 4 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).

#5 Updated by Gerrit Code Review over 4 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

#6 Updated by Gerrit Code Review over 4 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

#7 Updated by Gerrit Code Review over 4 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

#8 Updated by Gerrit Code Review over 4 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

#9 Updated by Anonymous over 4 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#10 Updated by Riccardo De Contardi over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF