-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Add the kernel.controller_arguments event #18440
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -61,7 +61,7 @@ protected function preDispatch($eventName, Event $event) | |
protected function postDispatch($eventName, Event $event) | ||
{ | ||
switch ($eventName) { | ||
case KernelEvents::CONTROLLER: | ||
case KernelEvents::CONTROLLER_ARGUMENTS: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. you're removing the stopwatch start on There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Taluu this is about starting the stopwatch for the controller execution itself. As there is now an event after the resolution of arguments, I starting it there now, as it makes the timing more accurate (in existing versions, the argument resolution is included in the controller time, even though it is also timed on its own) |
||
$this->stopwatch->start('controller', 'section'); | ||
break; | ||
case KernelEvents::RESPONSE: | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,55 @@ | ||
<?php | ||
|
||
/* | ||
* This file is part of the Symfony package. | ||
* | ||
* (c) Fabien Potencier <fabien@symfony.com> | ||
* | ||
* For the full copyright and license information, please view the LICENSE | ||
* file that was distributed with this source code. | ||
*/ | ||
|
||
namespace Symfony\Component\HttpKernel\Event; | ||
|
||
use Symfony\Component\HttpKernel\HttpKernelInterface; | ||
use Symfony\Component\HttpFoundation\Request; | ||
|
||
/** | ||
* Allows filtering of controller arguments. | ||
* | ||
* You can call getController() to retrieve the controller and getArguments | ||
* to retrieve the current arguments. With setArguments() you can replace | ||
* arguments that are used to call the controller. | ||
* | ||
* Arguments set in the event must be compatible with the signature of the | ||
* controller. | ||
* | ||
* @author Christophe Coevoet <stof@notk.org> | ||
*/ | ||
class FilterControllerArgumentsEvent extends FilterControllerEvent | ||
{ | ||
private $arguments; | ||
|
||
public function __construct(HttpKernelInterface $kernel, callable $controller, array $arguments, Request $request, $requestType) | ||
{ | ||
parent::__construct($kernel, $controller, $request, $requestType); | ||
|
||
$this->arguments = $arguments; | ||
} | ||
|
||
/** | ||
* @return array | ||
*/ | ||
public function getArguments() | ||
{ | ||
return $this->arguments; | ||
} | ||
|
||
/** | ||
* @param array $arguments | ||
*/ | ||
public function setArguments(array $arguments) | ||
{ | ||
$this->arguments = $arguments; | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a benefit of making the arguments mutable? Personally I would make this a constructor argument only until other cases really need this. If people want to alter the arguments, they should create an There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @iltar I'm not sure about that. Don't you think it would complicate things unnecessarily? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Imagine a case where I get 3 arguments: [ 0 => 'foo', 1 => 'bar', 2 => 'baz' ] I want to update the last element but I did Another issue is that you can't really do much at this point with those arguments. You don't have access to the metadata so if you want to do anything with introspection, you would have to (again) create the metadata or do it manually with reflection. Until there's a cached variant, the first is really not something I would advice. This would not be the correct hook to modify the arguments. I would rather get rid of the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. forbidding to alter the controller in a kernel.controller event would be a BC break though (and btw, the description of the kernel.controller event describes this as the use case of the event since Symfony 2.0). Btw, there are some cases where being able to alter arguments after they are resolved might be much easier than registering a value resolver, as it would mean that your value resolver has to duplicate the original resolution logic to add its own logic. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
My guess is that's because there's no other way to hook in on the controller generation at the moment
Do you have an example? I've been thinking of cases where this would be a viable alternative but I can't think of any There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
@iltar replacing the controller factory is possible since 2.0 thanks to dependency injection. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, you can implement your own I really don't mind if you keep the Would it be possible to log it if arguments have changed (even if only in dev)? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @iltar the usage of replacing the callable is not about introducing custom notations, but more about customizing the behavior of the controller callable, for instance by replacing it with a proxy object performing extra work before and after the action (JMSDiExtraBundle has such a use case, even though it decided to overwrite the ControllerResolver in a way making it unfriendly for people wanting to overwrite the resolver logic and using the listener would have been a better idea) |
||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence sounds more like a commit message which is is trying to be as short as possible. If you would change it slightly, it would sound a lot better:
kernel.controller_arguments
event, which is triggered after the controller arguments have been resolvedThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#18412 has just been merged, you need to rebase because of the changelog though.