flow-development-collection
flow-development-collection copied to clipboard
!!! FEATURE: PSR `ViewInterface` without controller context
Neos adjustments https://github.com/neos/neos-development-collection/pull/4856
- the views are now independent of the
ControllerContextViewInterface::setControllerContextis not part of the interface anymore and will only be called on demand
- the
ActionRequestif necessary can be accessed via the variable "request" (like "settings") ViewInterface::canRenderwere required for fallbackviews which have been removed long ago, and so this artefact will be removed as well.- !!! the return type is now forced to be either a
ResponseInterfaceor aStreamInterface. Simple strings must be wrapped in a psr stream!
Related to https://github.com/neos/flow-development-collection/pull/3232
@kitsunet That might be in conjunction with https://github.com/neos/flow-development-collection/pull/3232 an actual step to make the controllerContext obsolete?
But to still support martins use case and have the response always available https://github.com/neos/flow-development-collection/pull/3232#issuecomment-1910563163 i introduced a new ActionMessages dto, wich i pass secretly to the view under the key actionMessages like we do it with settings:
final readonly class ActionMessages
{
private function __construct(
public ActionRequest $request,
public ActionResponse $response
) {
}
public static function create(ActionRequest $request, ActionResponse $response)
{
return new self($request, $response);
}
}
This is the secret passing logic where we make the setControllerContext optional and only call it if existent:
$this->view->assign('actionMessages', ActionMessages::create($this->request, $this->response));
if (method_exists($this->view, 'setControllerContext')) {
$this->view->setControllerContext($this->controllerContext);
}
One could say that nothing changed but i think the ActionMessages is an improvement over the controller context as it offers less weird things.
Of course it would be ideal to not have to pass the pre-response anywhere but just work with the request - like my first commit shows, ~but that wouldnt allow many complex usecases.~ Edit no see my next comment...
Of course it would be ideal to not have to pass the pre-response anywhere but just work with the request - like my first commit shows, but that wouldnt allow many complex usecases.
yes that would be the goal. To only pass the request but not the Response outside of the view and its possible!!!
In this pr i found a way to make the neos fusion view work with plugins and fusion forms despite having no controller context at hand. https://github.com/neos/neos-development-collection/pull/4856
It works by creating a dummy controller context in the view and later rendering out that response from the view. That gives us the possibility to actually decouple views and controllers a lot. Simply by using the feature to render a psr response from a view.
The same i did in a much smaller scope for the json view, so that the content type is set automatically.
My prior ActionMessages gedöns has been reverted.
About ViewInterface::canRender
Initially canRender was introduced to allow special logic in a controller to determine the correct view out of multiple options. https://github.com/neos/flow-development-collection/commit/cb8fa242150ccdd8d5f9e7121c70c896efaaa62b
But with https://github.com/neos/flow-development-collection/commit/d69bcfe290a04b4079c8a764bb8a2c97b72d13d8 the canRender() checks were removed and leaves the method with zero usages and no real implementation.