[DX] Controller as a service, favoring tags over class level @Route() #12915
Comments
|
👍 |
|
@iltar the issue is that controllers and command resolving are totally different:
How would your tag work to build the route properly ? |
|
@stof I tried to do some research before I actually posted this suggestion, but my knowledge is still limited. From what I can see, the AnnotatedRouteControllerLoader does some guessing on whether it's supposed to be a service or not. Instead of trying to find out runtime if this is supposed to be a service, this can already be collected when collecting the tags during container compilation. During this process, it can be mapped as following: $controllers = [];
$tags = $container->findTaggedServiceIds('framework.controller');
foreach ($tags as $id => $tag) {
$controllers[$container->getDefinition($id)->getClass()] = $id;
}With this, you have a nice map:
Imo this only from a framework perspective. As developer I find it strange to add this in Having this information available because it's compiled gives other using app/console:
Tags would also allow other options to be passed along easily, without having to update an annotation, think about a priority to overwrite certain routes as simple example. |
But this would not allow answering this question either, given that only routes defined using annotations would require being tagged.
I don't see how this would answer this question.
Please don't try putting routing definition in the DIC config. It will be mixing things. |
|
I think I have another idea to solve this problem that the route (annotation) doesn't want to know the service id. We could say when a full class name is given in as a controller like This way you also don't need to annotate the service because the reflection would simply set the current controller class and action as _controller. This sounds so simple and intuitive to me. Am I missing something? |
|
... except that nothing is doing that right now; nowhere do we ask the DI for a service associated with a class name. The closer we had in the past is the interface support that was quickly dropped. |
|
And btw for anyone looking at @Tobion's suggestion again, this would break the support for controllers not defined as services, because |
Currently when using Controller as a Service with the SensioFrameworkExtraBundle, you will have to add an
@Route(service="acme_hello.controller.my_controller"). This feels unnatural, as it has nothing to do with routes.As of 2.4, Command as a Service was introduced. That made configuring the command really easy, you only have to add a tag to your service:
- { name: console.command }.My suggestion is to drop support for the
serviceoption in the@Route(and make both possible in 2.7) in favor of a tag on the service. The configuration could look like:This configuration feels far more natural and is in line with command configuration. I know this is supposed to be part if the SensioFrameworkExtraBundle, but getting feedback there is hard.
The text was updated successfully, but these errors were encountered: