RuleMatcher by Request attribute _controller does not work

[awdng]

The docs state a usage like attributes: { _controller: ^WhateverFrontendBundle:Page:.* } to match certain controllers/actions for caching, but i could not get it to work. After inspecting the Request object and the actual _controller value this is how i got it to work

attributes: { _controller: ^Whatever\\FrontendBundle\\Controller\\PageController\:\:.* }

Am i doing something wrong or is this a bug ?

[ddeboer]

I’m seeing the same behaviour (except you don’t need to escape :, so just :: works fine). @dbu Do you have any idea why the short controller names don’t work?

[stof]

Well, WhateverFrontendBundle:Page:index and Whatever\FrontendBundle\Controller\PageController::indexAction are both producing the same result for the controller (assuming the controller is not overwritten in a child bundle, in which case you should switch to the overwriting class and continue reading). Given that using the class name directly is a bit faster (no need to resolve the notation to the class name taking bundle overwrite into account), Symfony tries to resolve class name before dumping the UrlMatcher in the cache during the cache warmup to make things faster. This means that when using the app at runtime, the bundle notation is most of the time not used anymore by the _controller key.

If you have a matcher allowing to match on the _controller string, it should take this specificity into account (or warn about it so that users register 2 regexes to match both)

[ddeboer]

If you have a matcher allowing to match on the _controller string, it should take this specificity into account

Do you mean that we should advise users to configure controller matches by fully-qualified instead of abbreviated name?

[stof]

@ddeboer either you document that the regexes should match both notations (either with a complex regex, or with 2 separate regexes), or you make the matcher normalize the string so that regexes don't have to match 2 notations (and in this case, the choice would be to normalize to class names as the bundle notation cannot represent all class names) so that a single regex is enough.

Btw, your current matching also means that when switching to controllers as services, the user has to update matching rules to use the service id rather than the class name. Maybe the matching of controllers could be improved to match on something better than the _controller value.

[dbu]

hm, interesting problem. we are using the core symfony RequestMatcher here. would you happen to know if there is code somewhere in symfony to normalize the controller notation? as its (potentially) a regular expression, it could be quite tricky to expand. we probably need to point out to the user the details of what is happening, as stof explained here. so if he writes a complex regex, we can't expand that. or we could offer controller and controller_regex and not process controller_regex but controller. and require controller to match an actual existing controller class or service.

[ddeboer]

Let’s try to keep things simple. If _controller only contains the long controller name (Whatever\FrontendBundle\Controller\PageController::indexAction) and the short name is not available in any other Request properties either, let’s just advise users to match by long name regular expressions (so with \ escaping) only. As far as I can see, the short name is not available in Request at all.

[dbu]

so we add a .. warning:: there that says you can't use the short notation?

the nice thing of differentiating between regex or no would be that we can actually validate if that thing you match on actually exists... but yeah, lets keep it simple and hope that people test their stuff.

[dbu]

@ddeboer wdyt about adding the warning to explain what can be done in this field? i can do the PR, just need to know if you agree that would be the right solution.

[ddeboer]

Yeah, a warning is ok with me. Can you also check whether our doc examples use the correct notation?