10000 Feature request: Stop using service_id:method notation for _controller of routes · Issue #2751 · FriendsOfSymfony/FOSUserBundle · GitHub
[go: up one dir, main page]
Skip to content

Feature request: Stop using service_id:method notation for _controller of routes #2751

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.

Sign up for GitHub

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

Jump to bottom
Closed
spackmat opened this issue Mar 7, 2018 · 6 comments
Closed

Feature request: Stop using service_id:method notation for _controller of routes #2751

spackmat opened this issue Mar 7, 2018 · 6 comments

Comments

@spackmat
Copy link
spackmat commented Mar 7, 2018

Describe the feature:
Hi, since the bundle:controller:action and service:method notations are deprecated in Symfony 4.1 (see symfony/symfony#26085 for details), I would love to see FOSUserBundle to use the FQCN::method notation for the _controller setting of routes (or maybe everywhere).

Some background: I implemented a route access checker in my application reading @Security-Annotations of the controller actions, so I need to get the controller's class and the action from all routes in my application. At the moment, I have to access the container to get the class for the service of the fos_user_bundle routes (or ignore those routes in my checker). You can read more about this problem in this Stackoverflow question.
@stof
Copy link
Member
stof commented Mar 7, 2018

the FQCN::method notation does not work for controllers as services for older versions of Symfony that we still support, so this is not an option for us yet.

@spackmat
Copy link
Author
spackmat commented Mar 7, 2018

OK, I see. FQCN::method was introduced after Symfony 2.8, which is still .supported

But the new problem came with the change in FosUserBundle from 2.0 to 2.1. Before the routes were configured with for example FOSUserBundle:Security:logout, now it is fos_user.security.controller:logoutAction.

The old notation was resolved to FOS\UserBundle\Controller\SecurityController::logoutAction, when I retrieved it with $router->getRouteCollection()->get('fos_user_security_logout')->getDefault('_controller'), with the new one I get fos_user.security.controller:logoutAction instead.

Any other helpful input? I could use custom routes for FosUserBundle actions in my application instead using the new notation.

@stof
Copy link
Member
stof commented Mar 7, 2018

Well, we switched to controller defined as services in 2.1 to avoid having to keep all out internal services public in Symfony 4 (where private is the default) just because our controllers were using them.

On a side note, you should really avoid calling $router->getRouteCollection() at runtime. This is terrible for performance, as this triggers the loading of all routing resources (while the usage of the url generator and the url matcher will never load these resources after the cache warmup).
If you really need to know the mapping between routes and controller classes, you should generate such mapping in a cache warmer (and then you can also access service classes at that point from the container) and use this pre-generated map at runtime instead.

@spackmat
Copy link
Author
spackmat commented Mar 7, 2018

Thanks for this suggestion! I'll implement such a cache warmer then and solve the problem this way. Great idea.

@stof
Copy link
Member
stof commented Mar 8, 2018

I'm closing this issue because we cannot switch to the FQCN for now.

@stof stof closed this as completed Mar 8, 2018
@spackmat
Copy link
Author
spackmat commented Mar 8, 2018

I posted my implementation of a cached route-name-to-controller map as an answer to the stackoverflow question mentioned above: https://stackoverflow.com/a/49170148/2564552

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@spackmat @stof
0