!!! FEATURE: Render ResponseInterface directly in Fusion Views

[mhsdesign]

Neos Adjustments for neos/flow-development-collection#3286

• adjusts Views to return StreamInterface or an ResponseInterface
• adjusts Fusion runtime to return StreamInterface or an ResponseInterface

The fusion runtime will not accept the controller context from outside anymore, but instead has its own legacy layer.
The legacy layer only works in combination with the new entry point in the fusion runtime:

$httpResponse = $fusionRuntime->renderEntryPathWithContext('root', ['node' => $node]);

Fusion's FusionView adjustments:

The current view behaves incorrect. The ViewInterface allows to return string|ActionResponse|ResponseInterface|StreamInterface|\Stringable
But we violate this by returning the raw runtime value instead ... which for all we now could be a string but might also be just as annotated anything else (mixed) not included in the allowed return types, like raw arrays or non string-able objects or integers.
Also previously when using the Neos.Fusion:Http.Message in combination with the view it would actually render the http response as string, so HTTP/ was part of the content and visible in the dom (This is currently broken since Neos 8 and before).

To streamline the behaviour and fix these specialities, the FusionView will return if applicable a ResponseInterface and for simple (string) cases a psr StreamInterface. Both cases have to be anticipated on call site.
The change is not expected to be super breaking if a StreamInterface will be returned as for classes with loose typing this will be converted via __toString.

This is also necessary for Neos.Neos:Plugin and Neos.Fusion.Form to work correctly.

Resolves: #4855

Upgrade instructions

Mutating the response of the Fusion Runtime ($this->getRuntime()->getControllerContext()->getResponse()) is highly internal and only allowed for Neos special cases as the fusion plugin implementation and fusion forms. This will be removed when we find a better concept internally!

Also other usages of the getControllerContext are deprecated like accessing the request the following way:

$this->runtime->getControllerContext()->getRequest();

Instead, the new fusion globals #4425 should be used (which will also guarantee that the request in EEL ${request} is the same as when fetched from a Fusion object:

$possibleRequest = $this->runtime->fusionGlobals->get('request');
if (!$possibleRequest instanceof ActionRequest) {
    // ... fallback
}

If you use the Fusion Runtime directly, which is internal, you should know that using Runtime::render as entry point will fail to render Neos.Neos:Plugin, Neos.Fusion.Form and also lead to weird behaviour when rendering a Neos.Fusion:Http.Message.
The Fusion view should be used for interacting with Fusion, but if you must, you can leverage Runtime::renderEntryPathWithContext to render a full page with all special cases.

Review instructions / WHY

The WHY of this PR might not seem obvious as a lot of pieces fall here into place.

• We want to deprecate the controller context !!! 9.0 Deprecate controller context flow-development-collection#3152
  • -> But removing usages of the controller context is not easily doable as major parts of the system depend on it, like the fusion runtime
• This pr is part of a larger movement and will make Fusion independent of the controller context
• The controller context in Fusion is currently used for 2 major tasks
  1. accessing everything request related (the request itself, the uribuilder and flashmessages)
  2. accessing the current to be send response by object reference
• the first (i) is easily replaceable by migrating to use the Fusion global "request"
• the second (ii) is currently used for dark magic in Neos.Neos, we modify the to be send response by adding headers or changing the status code
  • in Neos.Neos:Plugin for sub-request link
  • in Neos.Fusion:Form to redirect on success to another page link
  • instead of creating a slightly prettier but still hacky api for these usecases (like $runtime->setHeader()) we will not change the syntax but deprecate it and internalise it.
  • to still support the usecases the Fusion runtime has to create a mutable object (a stub response) itself where it will extract the changes made to it and apply it to an actual reponse (merge it with the contents).
    • for that to archive we require to have a single entry point in Fusion to render a whole page (renderEntryPathWithContext)
    • and it requires this entrypoint to return something 'more' than the contents of the page, but also its headers: a full psr response
      • -> this is partially breaking
• to support this change the ViewInterface will be adjusted in Flow to force returning either a StreamInterface or an ResponseInterface, and also the setControllerContext will not be necessary to implement / call any longer on views.

Checklist

• Code follows the PSR-2 coding style
• Tests have been created, run and adjusted as needed
• The PR is created against the lowest maintained branch
• Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
• Reviewer - The first section explains the change briefly for change-logs
• Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

[mhsdesign]

this is actually a bugfix as the FusionView dindt handle Neos.Fusion:Http.Message before. Only the Neos FusionView did.

[mhsdesign]

this hack could be removed from the Neos FusionView and the view will use the new Runtime::renderResponse which will handle this.

[mhsdesign]

this method was only introduced in 9.0 dev thats why we can so easily remove it: #4425

[mhsdesign]

this logic was only introduced in 9.0 dev thats why we can so easily change it: #4425

[mhsdesign]

I can confirm that a Neos.Neos:Plugin works as described here neos/Neos.Demo#190

Though it needs an additional patch as plugins are currently broken on 9.0-dev anyways: #4909

Things i tested in the controller:

• forward (content of other action)
• throwStatus (500 will be upmerged and plugin will show text inside: 500 Internal Server Error
• redirect (uri will change)
• set arbitrary header x-mhs: foobar
• build uri to another action
• render fluid view
• render string

[kitsunet]

Yes!