Project

General

Profile

Actions

Feature #104393

open

Bad performance ot AfterRequestDispatchedEvent

Added by David Bruchmann about 11 hours ago. Updated about 9 hours ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Extbase
Target version:
Start date:
2024-07-15
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

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);
Actions #1

Updated by David Bruchmann about 10 hours ago

  • Description updated (diff)
Actions #2

Updated by David Bruchmann about 10 hours ago

  • Description updated (diff)
Actions #3

Updated by David Bruchmann about 10 hours ago

  • Description updated (diff)
Actions #4

Updated by Garvin Hicking about 10 hours ago

Could you maybe describe a use case for this, so the need for it could be better understood? Do you try to listen on specific actions being executed that are not under your control?

Actions #5

Updated by David Bruchmann about 9 hours ago

Garvin, I thought about using it but am not sure if that's the best solution for my case.
It's about introducing another aspect, that is not available by headers or URL, to decide about the controller. That could be a setting in the extension settings which are stored in config/system/settings.php as example.
In my use-case I tend to decide against it, as it's not flexible but rather a one-time decision the user has to do -- this might be acceptable in different use-cases though.

Actions

Also available in: Atom PDF