-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Routing] PSR-4 directory loader #47916
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
Conversation
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.
Nice one!
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php
Outdated
Show resolved
Hide resolved
83ee61d
to
3d0f3cb
Compare
If we accept this feature, we can consider deprecating |
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php
Outdated
Show resolved
Hide resolved
3a37b7f
to
d5552b8
Compare
d5552b8
to
c3aef36
Compare
src/Symfony/Bundle/FrameworkBundle/Tests/Functional/Psr4RoutingTest.php
Outdated
Show resolved
Hide resolved
c3aef36
to
11a55ad
Compare
3a02ca9
to
beca77d
Compare
Recipe: symfony/recipes#1136 |
Could we make the namespace root part ( |
The |
...ymfony/Component/Routing/Tests/Fixtures/Psr4Controllers/SubNamespace/IrrelevantInterface.php
Outdated
Show resolved
Hide resolved
What about replacing |
It would be more consistent with the other loaders, yes. Let's try that. This way, the namespace would in fact become optional because if you omit it, the old |
046ef87
to
a31b27d
Compare
Done. I like the change. I'll update the recipe and the docs right away. |
Should I rename |
Nah, not needed IMHO. |
a31b27d
to
158e30d
Compare
Thank you @derrabus. |
…loading (derrabus) This PR was merged into the 6.2 branch. Discussion ---------- [Config][Routing] Nicer config syntax for PSR-4 route loading | Q | A | ------------- | --- | Branch? | 6.2 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | Follow-up to #47916 | License | MIT | Doc PR | symfony/symfony-docs#17373 (WIP) This PR implements an alternative syntax for the PSR-4 route loader introduced in #47916. ```YAML controllers: resource: path: ./Controllers namespace: App\Controllers type: attribute ``` ```XML <routes> <import type="attribute"> <resource path="./Controllers" namespace="App\Psr4Controllers" /> </import> </routes> ``` Commits ------- d7df3be Nicer config syntax for PSR-4 route loading
This PR was merged into the 6.2 branch. Discussion ---------- Document the PSR-4 route loader This PR documents symfony/symfony#47916 Although the PR does not deprecate `AnnotationDirectoryLoader` and `AnnotationFileLoader`, I chose to recommend only the new `Psr4DirectoryLoader` and `AnnotationDirectoryLoader` in `routing.rst`. In `routing/custom_route_loader.rst`, all four loaders are listed for completeness. Using a class name as resource instead of a file path has always worked, but wasn't documented for some reason. I have added examples for that as well. Commits ------- ac2f793 Document the PSR-4 route loader
…iles (derrabus) This PR was merged into the 6.2 branch. Discussion ---------- [Routing] Add tests for loading PSR-4 classes from PHP files | Q | A | ------------- | --- | Branch? | 6.2 | Bug fix? | no | New feature? | no | Deprecations? | no | Tickets | N/A | License | MIT | Doc PR | N/A Follow-up to #47916, #47943 This PR adds more tests, demonstrating how to trigger the new PSR-4 loader from a PHP config file. Commits ------- 416639c Add tests for loading PSR-4 classes from PHP files
I think it makes sense. The AnnotationFileLoader seems to assume the class is autoloadable anyway (it does not include the file manually). So it basically requires an autoloading config anyway which is very likely psr-4. Btw, wouldn't it be usefull if composer offered an API to query what namespace is expected in a directory (and the other way round). Then we could re-use the information composer already has. |
This PR adds a PSR-4 directory loader to the Routing component.
When we currently want to load routes from a directory with controllers, we configure it like this:
What happens now is that
AnnotationDirectoryLoader
searches that directory recursively for*.php
files and uses PHP's tokenizer extension to discover all controller classes that are defined within that directory. This step feels unnecessarily expensive given that modern projects follow the PSR-4 standard to structure their code. And if we use the DI component's autodiscovery feature to register our controllers as services, our controller directory already has to follow PSR-4.A client I'm working with adds the additional challange that they deliver their code to their customers in encrypted form (using SourceGuardian). This means that the PHP files contain encrypted bytecode instead of plain PHP and thus cannot be parsed. We currently overcome this limitation by extending
AnnotationDirectoryLoader
and overriding the protectedfindClass()
method.This PR proposes to extend the resource type
attribute
and allow to suffix it with a PSR-4 namespace root.In order to use PSR-4 to discover controller classes, the directory path is not enough. We always need an additional piece of information which is the namespace root for the given directory. Without changing large parts of the Config component, I did not find a nice way to pass down that information to the PSR-4 route loader. Encoding that information into the
type
parameter seemed like the pragmatic approach, but I'm open to discussing alternatives.This approach should play nicely with projects that already use attributes for routing and PSR-4 autodiscovery to register controllers as services. In fact, most project should be able to swap the
type: annotation
ortype: attribute
config withtype: attribute@Your\Namespace\Here
and the only difference they notice is that router compilation becomes a bit faster.