DISCUSSION: How to avoid in fusion access to `$this->runtime->getControllerContext()->getResponse()`? about neos-development-collection HOT 7 OPEN

That would obviously only work for uncached segments to manipulate that global state but still.

Wouldn't that be already the state we have now? If a cached fusion object manipulates the response, that will happen only on the first uncached render and not on subsequent ones.

from neos-development-collection.

How about just having a FusionRuntime->mergeResponse($additionalResponse) and internally the FusionRuntime carries a response around, which is merged in the HttpResponseImplementation?

SomeFusionObjectImplementation {
   render() {
      // warning this only works if the object is evaluated consistently via mode=uncached.!!!
      $myResponse = new ActionResponse();
      $myResponse->....doStuff/setHeaders
      $runtime->mergeResponse($myResponse);
   }
}

from neos-development-collection.

Wouldn't that be already the state we have now? If a cached fusion object manipulates the response, that will happen only on the first uncached render and not on subsequent ones.

exactly, so no change here.

It worked actually out quite good and even with a working legacy layer so neos fusion form still works :D

And any code interacting with $this->runtime->getControllerContext()->getResponse(); :D

#4856

from neos-development-collection.

Sadly it seems it doesnt work perfectly and there are test cases to proof it :D

The header, if existent in the the parent response is currently duplicated and not correctly overridden:

The whole replaceHttpResponse / buildHttpResponse is a bit flaky, see neos/flow-development-collection#2492

I dont think its unfixable we just have to find a way.

from neos-development-collection.

I think multiple competing headers like that are a broken use case anyways. Headers by definition can appear multiple times, we can't really know if we should remove the first one and when not. IMHO the test is misleading the result might as well (correctly) be key => [value, value]

It shows a potential use case for the exceptions though, if you actualyl want to redirect the main request from within a plugin
you kinda have be able to throw to escape your plugin prison. Not sure how well that actually works with the code base right now as the plugin has it's own dispatch loop, but that could be a valid reason. I don't think status codes upmerging makes any sense as it's always unclear what should win. What if there are two plugins on the page? Either we allow it by excepting and thereby preventing the second plugin from even running, or we don't allow it at all.

from neos-development-collection.

It shows a potential use case for the exceptions though, if you actualyl want to redirect the main request from within a plugin
you kinda have be able to throw to escape your plugin prison. Not sure how well that actually works with the code base right now as the plugin has it's own dispatch loop, but that could be a valid reason.

As far as i can tell that cannot work due to the own loop. A ForwardException will be catched and handled there and the forward will only affect the plugin subrequest and the main request is not forwarded. So i would not say that this is a reason for exceptions, especially considering that no one might need that feature...

I don't think status codes upmerging makes any sense as it's always unclear what should win. What if there are two plugins on the page? Either we allow it by excepting and thereby preventing the second plugin from even running, or we don't allow it at all.

well yes i agree it all is a bit muddy, but @mficzel relies on some behaviour to upmerge a redirect (with status code) for the Neos.Fusion.Form.Runtime:Redirect action:

https://github.com/neos/fusion-form/blob/642f728976bd205205ce76180b4c701a67adb30c/Classes/Runtime/Action/RedirectAction.php#L44

https://github.com/neos/fusion-form/blob/642f728976bd205205ce76180b4c701a67adb30c/Classes/Runtime/FusionObjects/RuntimeFormImplementation.php#L172-L174

but sure if there are other headers set or things rendered the redirect will just win without question (even in the fusion form, a returned action Message will be just ignored / never shown). Its wild west.

from neos-development-collection.

I think we should keep at first the proposed unsafeAdditionalDynamicHeaders/ unsafeHttpResponseConstrains feature out of the game.

Fusion objects interacting with $this->runtime->getControllerContext()->getResponse()->set... are hacky as it is and changing the part $this->runtime->getControllerContext()->getResponse() to $this->runtime->bla is just syntactic sugar.

What is important that the controller context available will not be the actual controller context from the controller but self crafted by the fusion runtime which will be used to return the psr response.

At some point we might actually find out what we want to support, headers, redirects or status codes by plugin and by then we can decide on a nice api.

from neos-development-collection.