Change in Forward plugin behavior in Beta4

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Change in Forward plugin behavior in Beta4

I've discovered 2 changes in behavior of the Forward controller plugin while playing with latest master.

I spoke to Matthew and Evan about this first one briefly in IRC, but here is some more detail. When the forward plugin determines the locator has a ControllerLoader, it sets $scoped to true and doesn't inject the event into the controller. The ControllerLoader is also not injecting an event, so it ends up using the default one created in ActionController::getEvent(); I believe it needs to have the event from the Forward plugin so that it gets the RouteMatch with the params passed into Forward::dispatch.

Worth noting, in the regular MVC lifecycle, the event is NOT injected into the controller by the ControllerLoader, it is injected by the DispatchListener:

I think the solution to this is to move the setEvent outside of the !$scoped block.

After the temporary fix to the above, the second issue I found is more to do with the changes in the InjectTemplateListener, but manifests itself when using the Forward plugin. When Forward dispatches the ActionController, the target of the event is set to the new controller. When exiting the Forward plugin, the target of the event is never changed back to the original controller. So when the InjectTemplateListener runs, it uses the target of the event:

The reason this used to work is the InjectTemplateListener used to get the controller portion by getting the routeMatch parameter and the RouteMatch is restored by the Forward plugin before returning. I'm thinking we should reset the event target after forwarding, or maybe do forwarding with a cloned event instance.

-Nick (SocalNick)