TYPO3 Core

The `AfterRequestDispatchedEvent` is triggered after the content is completely rendered, even including the view.
If an action of another controller shall be rendered this adds up to the needed time and performance.

Therefore I propose another event, after the controller is resolved:

            $controller = $this->resolveController($request);
            $this->eventDispatcher->dispatch(new AfterControllerResolvedEvent($controller, $request));
            $response = $controller->processRequest($request);

As the code `$controller->processRequest($request)` triggers determination of the action too, the new Event wouldn't cover cases where just another action of the same controller should be dispatched individually, though.
To achieve this the code inside `ActionController::processRequest` had to be changed, so that determining the action would be separated from processing. This would be a deeper change though, but probably better and more reasonable than the proposed event.
When these two steps are separated it would be possible to include an event where controller and action are known already. Just forwarding wouldn't be included as that's done from inside the actions.

            $controller = $this->resolveController($request);
            $action = $this->resolveControllerAction($request);
            $this->eventDispatcher->dispatch(new AfterControllerActionResolvedEvent($controller, $action, $request));
            $response = $controller->processRequest($request);

Target of new Event is having the option to alter the dispatcher result, specifically to change Controller and/or Action, even if my code example wouldn't provide this feature.

In the frontend as well on many levels for developers this would be a hidden feature and hard to discover without knowledge about it's existence, similar to AOP where this problem exists too.

Examples:
- An extension provides wiki-pages for kids and adults, the level is different and could be switched based on the usergroup, without having to adjust this in the controller. Instead for each usergroup an own controller and view could be realized without much efforts.
- Shops / Banks / Assurances could provide different pages base on location or target group.