!!! FEATURE: ViewInterface returns PSR StreamInterface

[mhsdesign]

Neos adjustments neos/neos-development-collection#4856

• the views are now independent of the ControllerContext
  • ViewInterface::setControllerContext is not part of the interface anymore and will only be called on demand
• the ActionRequest if necessary can be accessed via the variable "request" (like "settings")
• ViewInterface::canRender was 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 ResponseInterface or a StreamInterface. Simple strings must be wrapped in a psr stream! (see StreamFactoryTrait::createStream)

Related to #3232

[mhsdesign]

@kitsunet That might be in conjunction with #3232 an actual step to make the controllerContext obsolete?

But to still support martins use case and have the response always available #3232 (comment) 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...

[mhsdesign]

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. neos/neos-development-collection#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.

[mhsdesign]

About ViewInterface::canRender

Initially canRender was introduced to allow special logic in a controller to determine the correct view out of multiple options. cb8fa24

But with d69bcfe the canRender() checks were removed and leaves the method with zero usages and no real implementation.

[kitsunet]

Will this even show in IDEs with the function commented out? bit nasty I guess 🤷

[mhsdesign]

documenting this via

@method setControllerContext(ControllerContext $controllerContext) @deprecated
on the view-interface will not have the desired effect of annotating it as deprecated but would still allow goto clicking.

In the end all views extend the AbstractView which still contains a definition for setControllerContext (but deprecated) so i guess its fine?

[kitsunet]

I think the more important headline this PR should have is View returns Stream, because that will hit many peoples feet updating to this. I think it's a good direction, minor comments, probably overlooked osmething, probably something needs fixing in the future, but we should do it.

[mhsdesign]

One last question, do we want to use request as naming here or preserve that slot for a pretty psr request, despite that in Fusion request is an ActionRequest (which will not change anytime?)

Do we all agree to keep the ActionRequest for some time and have it hold all the context, like matched controller, base uri and routing parameters?