[BUGFIX] Preserve parent ViewHelperVariableContainer in ComponentRend… - #1387
Conversation
…erer Components previously received a fresh ViewHelperVariableContainer, cutting them off from context set up by outer ViewHelpers such as TYPO3's FormViewHelper. As a result, form field ViewHelpers used inside a component could not resolve their name attributes correctly and were not registered for "trustedProperties", causing submitted values to be discarded during property mapping. Reuse the parent's ViewHelperVariableContainer instead of creating a new one, so outer context stays available inside components. To keep slots isolated for nested components, the previous slot state is saved before rendering and restored afterwards.
|
This is intended behavior and part of the isolation of components. They should produce minimal side effects, which is why they receive their own viewhelper variable context. From my point of view, this should be addressed on the TYPO3 site by handing around a state object in form ViewHelpers instead of creating a lot of implicit connections between ViewHelpers – even across template files. |
|
I understand the intention behind isolating components, and I agree that using an explicit state object would be a cleaner design than relying on the ViewHelperVariableContainer. One detail that may not be obvious from the description: the change does not simply replace the component-local slot state with the parent's state permanently. Before rendering a component, the existing slot entries are saved, the component's slots are installed temporarily, and the previous slot entries are restored afterwards. So nested components still have isolated slot state. However, this is how TYPO3's FormViewHelper works today. Replacing the parent's ViewHelperVariableContainer means that components can no longer participate in an enclosing f:form, which is a regression compared to sitegeist/fluid-components and breaks existing templates during migration. From a user's perspective, using a form field ViewHelper inside a component that is rendered within an f:form is a reasonable expectation. With the current implementation, this silently produces invalid forms because field names are no longer registered for __trustedProperties. |
Ah, I was under the impression that we did it in the same way back then. Seems like we didn't: I'll leave this PR open. I'm currently busy with client work, but I'll discuss this with others and come back to it. |
|
@giesenmartin Could you force-push your branch to trigger the pipelines? I believe there was an issue with GitHub Actions. |
2 participants
…erer
Components previously received a fresh ViewHelperVariableContainer, cutting them off from context set up by outer ViewHelpers such as TYPO3's FormViewHelper. As a result, form field ViewHelpers used inside a component could not resolve their name attributes correctly and were not registered for "trustedProperties", causing submitted values to be discarded during property mapping.
Reuse the parent's ViewHelperVariableContainer instead of creating a new one, so outer context stays available inside components. To keep slots isolated for nested components, the previous slot state is saved before rendering and restored afterwards.