Use PHP to define the services and routes of the app #721
Conversation
|
There is a lot of documentation and tutorial content that will become confusing when this change is made. SymfonyCasts doesn't generally refer to PHP service/route configuration even being a possibility, every example is based on the |
|
The validation error from the bot is a bug /cc @fabpot :) |
Yea, this is the BIG cost - not to be taken lightly. I think it's at least good to explore though. In practice, if we were to make a big recipe change like this, it makes more sense on a major version (even if the major version doesn't contain the feature that's required to power the recipe). Then you can say "Oh, in Symfony 6, it's done this new way". For SymfonyCasts, if we made this change for 5.1, then any Symfony 5 screencasts we make between now and May (next 5ish months) will have a big outdated piece. I don't think it's worth it - especially because |
|
Thanks for proposing this feature! I like it a lot ... but I have a minor comment: I agree with Yonel and Maxime ... I like this approach, but I'd prefer to keep the config/services.php and config/routes.php files. I think it makes things easier to understand, especially for newcomers, and also solves the problem that would make the Kernel class grow too much (up to thousands of lines) when you have lots of routes or services. |
|
The Kernel holds nothing but configuration. The Kernel is configuration. Look at it. Like I mentioned to @yceruto, the Kernel is actually much better than a random file in a folder, because it has context: the All these are the heart of a better configuration system that works with autocompletion. |
|
I also disagree. If one ends up having a big Kernel, it means that on each HTTP request, this "big kernel" is loaded for no reason (loaded, not executed). Contrary to Also, Kernel is documented and explained as the "app encapsulator". App config is mostly in An alternative to provide such direct example and demonstration would be a special skeleton or generator to create a single-file app with only the Kernel. |
|
I cracked it, the DI+Routes config are now split from the Kernel. |
|
Considering most people are comfortable using YAML for services and routes, I don't see the need to change the default to PHP. If people want to use this, they can easily do so in their app as this PR shows. But I don't think it's a good idea to make this the new default at this point. |
|
This is awesome! Programming PHP applications with PHP! No, I am not being ironic ^^ For PHP developers not that familiar with Symfony, this is conceptually simpler to use PHP than learning a Symfony-specific DSL written in YAML. A PHP API is familiar and discoverable easily (with any IDE) without having to keep the docs on a second screen. It makes sense that experienced Symfony developers might not see the point in this (after all, what is the problem to fix here?), but I think it may go a long way for casual Symfony developers or junior developers. (by "casual" I mean developers, me included, that know the framework but not enough to remember all the details) ❤️ this PR! |
|
I think there is more to the debate than just "why do we need YAML anyway?" . I have 2 main concerns with this approach:
|
|
I also agree with this feature. It's time to move forward to "proper" conventions! Yaml has never been a good convention IMO. It's only positive value is the fact that it can be easily read. But indentation, complete lack of documentation and validation, etc. (parsing time? :p ) make it a bad practice at first sight. There's also the fact that newcomers (I've seen that too much since I'm a Symfony teacher) are keen to believe that their Yaml config looks similar when defining extensions configuration, services definitions, parameters, routing, fixtures (using Faker and some fixtures-related libs that use Yaml), ORM mapping, and many other things that we can define in Yaml these days. Many developers argue that XML is the best choice because of the XSD file that make it documented, auto-completed in ANY code editor (since XML has been here for 22 years and XSD for 16 years). I'm on the side of the ones that like compromises, and the best compromise to me is to use the native API in PHP. This way, native auto-completion is possible, dynamic loading is possible too (like in Compiler Passes, in the end...), environment-specific config becomes possible in one single file (something impossible in Yaml), etc. Laravel, in comparison, is one of the most popular frameworks, and there's no sign of Yaml in its default configuration. All of it is plain PHP arrays, which is similar than Yaml in its readability, and some parts are using some OOP like routes. It's not perfect (at all, I said a lot about this in a tweeter feed some time ago), but still, it's PHP, and people are used to it. The benefits of using PHP are numerous, compared to Yaml which only has one. |
…DSL configurators (nicolas-grekas) This PR was merged into the 5.1-dev branch. Discussion ---------- [DI][Routing] add wither to configure the path of PHP-DSL configurators | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - This makes PHP-DSL configurators more flexible, by allowing to use them for a different path than they were initially created for. Sidekick of symfony/recipes#721 Commits ------- 8f92c85 [DI][Routing] add wither to configure the path of PHP-DSL configurators
ghost
deployed
to
| if ('test' === $kernel->getEnvironment()) { | ||
| // When a test case needs access to a service, getting it via | ||
| // a public alias with the "test." prefix is recommended. | ||
| $services->public() | ||
| // ->alias('test.App\MyService', App\MyService::class) | ||
| ; | ||
| } |
There was a problem hiding this comment.
Won't this be a readability issue when projects grow and test overrides become more numerous? Shouldn't we stick to services_test.php as usual?
There was a problem hiding this comment.
that's why I preferred having everything in the Kernel, as that allowed for using methods to split the code :)
But anyway, this can be added later on, on projects that actually need it.
There was a problem hiding this comment.
This section isn't needed anymore, as we removed the services_test.yaml file (there is that test container where everything is public)
|
oups :) |
|
For the record, while I really like this, I'm -1 for doing it now. A big change like this should be done on a major release - it’s confusing for important files to disappear from 5.0 to 5.1. It also has huge effects on docs and screencasts. That’s manageable if we do it on a major release - but not in a minor release. |
This PR is here to demonstrate the new capabilities of Symfony 5.1.
Basically, we can now develop a full Symfony app in a single file, like "microframeworks"
No
services.yaml, noroutes.yamlhere.