Project

General

Profile

Actions

Bug #66533

closed

Paths not possible if array used as form object

Added by Philipp Wrann about 9 years ago. Updated over 6 years ago.

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

100%

Estimated time:
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...

Actions #1

Updated by Benni Mack almost 9 years ago

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

Updated by Susanne Moog over 8 years ago

  • Target version changed from 7.4 (Backend) to 7.5
Actions #3

Updated by Benni Mack over 8 years ago

  • Target version changed from 7.5 to 7 LTS
Actions #4

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

Actions #5

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

Actions #6

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

Actions #7

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

Actions #8

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

Actions #9

Updated by Anonymous over 8 years ago

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

Updated by Riccardo De Contardi over 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF