Task #90289
closedAbstractViewHelper class of TYPO3 8.7 can be compatible with Fluid 3.0 with minor changes
100%
Description
The following changes will make AbstractViewHelper from TYPO3 8.7 compatible with Fluid 3.0:
- A condition must be added in registerRenderMethodArguments which checks if method_exists($this, 'render') before attempting to use Reflection to fetch arguments, since render() is optional in Fluid 3.0
- The assigning of $this->controllerContext = $this->renderingContext->getControllerContext(); must be duplicated from prepareArguments to an overridden getArguments function (since prepareArguments is not called by Fluid 3.0 when creating the instance, but getArguments will)
- The foreach of $this->argumentDefinitions in callRenderMethod must be changed to foreach $this->prepareArguments since $this->argumentDefinitions does not exist in Fluid 3.0
- A condition must be added in registerRenderMethodArguments which assigns the ArgumentDefinition to a temporary variable $argumentDefinition and if ($this->arguments instanceof ArgumentCollection), call $this->arguments->addDefinition($argumentDefinition). Otherwise, assign into $this->argumentDefinitions.
Updated by Gerrit Code Review almost 5 years ago
- Status changed from New to Under Review
Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63136
Updated by Gerrit Code Review almost 5 years ago
Patch set 2 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63136
Updated by Gerrit Code Review almost 5 years ago
Patch set 3 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63136
Updated by Gerrit Code Review almost 5 years ago
Patch set 4 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63136
Updated by Gerrit Code Review almost 5 years ago
Patch set 5 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63136
Updated by Gerrit Code Review almost 5 years ago
Patch set 6 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63136
Updated by Anonymous over 4 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 8a6c9a4beda16f469a5f1a123ebc7a345b20dc10.
Updated by Oliver Hader over 4 years ago
- Related to Bug #91401: Fluid AbstractViewHelper::getArguments incompatibilities added
Updated by Felix Buenemann over 4 years ago
This changes the return type of TYPO3\CMS\Fluid\Core\ViewHelper\AbstractViewHelper::getArguments()
from array
to ArgumentCollection
which causes downstream classes that inherit from the view helper to be incompatible, if the implement getArguments()
without the type declaration as noted in #91401.
So this means this is a breaking change in a minor version and needs to be fixed.
Shouldn't it be possible to avoid the type declaration in the method definition of getArguments()
and instead do manual type coercion as needed?
Updated by Felix Buenemann over 4 years ago
Btw. where can the Fluid 3.0 source code be found? – I checked https://github.com/TYPO3/Fluid, but the newest tag is 2.6.9. (already found it in the 3.0 branch)
Updated by Felix Buenemann over 4 years ago
OK, looks like \TYPO3Fluid\Fluid\Core\ViewHelper::getArguments()
in Fluid 3.0 (https://github.com/TYPO3/Fluid/blob/3.0/src/Core/ViewHelper/AbstractViewHelper.php#L48) depends on the ArgumentCollection
return type, so the idea I suggested above won't work:
The enforcement of the declared return type during inheritance is invariant; this means that when a sub-type overrides a parent method then the return type of the child must exactly match the parent and may not be omitted. If the parent does not declare a return type then the child is allowed to declare one. (quote from https://wiki.php.net/rfc/return_types)
Any other ideas how to work around the problem without changing downstream code?