Use PHP instead of XML as the prefered service/route configuration in core #36778
Conversation
|
Will we sign configuration values from environment variables using Edit: I jumped on this too quick. The updates posted as I was commenting answer my questions. |
| ->tag('container.preload', ['class' => 'Twig\Template']) | ||
| ->tag('container.preload', ['class' => 'Twig\TemplateWrapper']) | ||
|
|
||
| ->alias('Twig_Environment', 'twig') |
There was a problem hiding this comment.
pretty strange to me that this is not bound to the service that was defined before. can't we make e.g. $container->services()->set('twig', Environment::class)->alias('Twig_Environment') possible?
There was a problem hiding this comment.
This would be based on no factual ground: aliases are standalone things, suggestion something else would create confusion eventually to me.
There was a problem hiding this comment.
Sure it should be possible to create aliases standalone. But in most cases you will add an alias on a service you just created like in this example here. Then it makes sense to me not to repeat the service id again avoiding typos. And it reads much better.
There was a problem hiding this comment.
But this would remove any possibility to configure the alias (ServiceConfigurator()->alias() returns a configurator for the alias, but in your proposal, we would need to stay in the service configuration).
Also, it cannot be called ->alias(), as that method name is already taken to start a new alias.
And to me, making the PHP DSL define aliases from the service configuration could introduce confusion about how aliases work (and that would not be consistent with other configuration formats btw).
|
|
||
| ->set('data_collector.twig', TwigDataCollector::class) | ||
| ->args([ref('twig.profile'), ref('twig')]) | ||
| ->tag('data_collector', ['template' => '@WebProfiler/Collector/twig.html.twig', 'id' => 'twig', 'priority' => 257]) |
There was a problem hiding this comment.
An idea: we could create an interface for tags as classes.
interface ContainerTagInterface
{
public function getName(): string;
public function getAttributes(): array;
}
then allow something like ->tag((new DataCollectorTag)->template('...')->id('twig')->priority(257)) which makes tags discovorable, autocomplete, supporting types and documentable in code.
There was a problem hiding this comment.
For ref, discoverable tags as constants for usage in the PHP config were discussed a bit in #24377
196118f to
ad3c202
Compare
This PR was squashed before being merged into the 5.1-dev branch. Discussion ---------- [DI] Renamed some PHP-DSL functions | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - As discussed in #36778, Symfony wants to move from XML to PHP for its own configuration. I propose these function renames to make the PHP-DSL a bit easier to understand: ```php <?php // Before $services->set(Foo::class) ->args([ref(Bar::class), service('stdClass')]); // After $services->set(Foo::class) ->args([service(Bar::class), inline_service('stdClass')]); ``` Commits ------- 366405b [DI] Renamed some PHP-DSL functions
|
PR rebased and ready for merge. |
238fe2b to
5e0d2e9
Compare
| $files = Finder::create()->files()->name('*.php')->path('Resources')->notPath('Tests')->in(\dirname(__DIR__, 5)); | ||
| foreach ($files as $file) { | ||
| $contents = file_get_contents($file); | ||
| if (preg_match_all("{->tag\('([^']+)'}", $contents, $matches)) { |
There was a problem hiding this comment.
To be consistent with what is done for XML files, should we also look for tagged iterator arguments ?
There was a problem hiding this comment.
Yes, will do when I have an example :)
In Symfony 6, I (we?) would want to promote usage of configuration written in PHP instead of YAML. For third-party bundles and core, we should do the same, replacing XML with PHP. Doing so would remove the need for the XML lib for core.
The biggest advantage is auto-completion with any modern IDE without explicit support for Symfony, and probably one less thing to learn (how to configure things in YAML/XML).
Be warned that it does NOT concern semantic configuration which is much harder.
This PR does the work for the Twig bundle as an example. Once we agreed on the CS, the same should then be done for other core bundles both for service configuration and route configuration.
Embeds #36775 until it is merged.