[DependencyInjection] Add "instanceof" section for local interface-defined configs #21530
Conversation
ae6c98f to
1948bcd
Compare
|
what happens when you use a parameter as class name for the service (which is still supported even though we discourage its usage in the doc) ? |
| @@ -26,7 +26,7 @@ class ChildDefinition extends Definition | |||
| private $changes = array(); | |||
|
|
|||
| /** | |||
| * @param string $parent The id of Definition instance to decorate | |||
| * @param string|null $parent The id of Definition instance to decorate | |||
There was a problem hiding this comment.
I don't like the idea of allowing null here. A ChildDefinition registered in the container must not have a null parent id (it would break things).
If you use a ChildDefinition temporarily to resolve instanceof configurations in the loaders, I would rather use a dummy parent id (which will not go outside the loader anyway)
|
what happens when the service class matches multiple |
1948bcd to
28b7922
Compare
the class is resolved using the parameterbag already.
they are applied on top of each others in declaration order
nothing special: we use the "class" attribute, which we deprecated not defining, so we can use "instanceof" even in the case of factories. |
| @@ -356,6 +357,24 @@ public function getOverriddenGetters() | |||
| } | |||
|
|
|||
| /** | |||
| * @experimental in version 3.3 | |||
| */ | |||
| public function setInstanceofConditionals(array $instanceof) | |||
There was a problem hiding this comment.
we should document the type of the argument (what is inside the array ?)
| /** | ||
| * @experimental in version 3.3 | ||
| */ | ||
| public function getInstanceofConditionals() |
There was a problem hiding this comment.
we should document the returned type (an array of something, but what ?)
24d8139 to
8f5a69d
Compare
| } | ||
|
|
||
| /** | ||
| * Gets the definition templates to conditionally apply on the current definition, keyed by parent interface/class |
9f89907 to
a06d87c
Compare
236cd01 to
c611187
Compare
|
👍 |
| { | ||
| if ($this->isLoadingInstanceof) { | ||
| if (!$definition instanceof ChildDefinition) { | ||
| throw new InvalidArgumentException(sprintf('Invalid type definition "%s": ChildDefinition expected, %s given.', $id, get_class($definition))); |
c611187 to
773eca7
Compare
|
Thank you @nicolas-grekas. |
…al interface-defined configs (nicolas-grekas, dunglas) This PR was merged into the 3.3-dev branch. Discussion ---------- [DependencyInjection] Add "instanceof" section for local interface-defined configs | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - This is a direction follow up of #21357 on which we're working together with @dunglas. From the description posted there: There is some work being done to include features of [DunglasActionBundle](https://github.com/dunglas/DunglasActionBundle) in the core of Symfony. The goal of all those PRs is to improve the developper experience of the framework, allow to develop faster while preserving all benefits of using Symfony (strictness, modularity, extensibility...) and make it easier to learn for newcomers. This PR implements the tagging feature of ActionBundle in a more generic way. It will help to get rid of `AppBundle` in the the standard edition and to register automatically some classes including commands. Here is an example of config (that can be embedded in the standard edition) to enable those features: ```yaml # config/services.yml services: _defaults: autowire: ['get*', 'set*'] # Enable constructor, getter and setter autowiring for all services defined in this file _instanceof: Symfony\Component\Console\Command: # Add the console.command tag to all services defined in this file having this type tags: ['console.command'] # Set tags but also other settings like "public", "autowire" or "shared" here Twig_ExtensionInterface: tags: ['twig.extension'] Symfony\Component\EventDispatcher\EventSubscriberInterface: tags: ['kernel.event_subscriber'] App\: # Register all classes in the src/Controller directory as services psr4: ../src/{Controller,Command,Twig,EventSubscriber} ``` It's part of our 0 config initiative: controllers and commands will be automatically registered as services and "autowired", allowing the user to create and inject new services without having to write a single line of YAML or XML. When refactoring changes are also automatically updated and don't require to update config files. It's a big win for rapid application development and prototyping. Of course, this is fully compatible with the actual way of defining services and it's possible to switch (or mix) approaches very easily. It's even possible to start prototyping using 0config features then switch to explicit services definitions when the project becomes mature. Commits ------- 773eca7 [DependencyInjection] Tests + refacto for "instanceof" definitions 2fb6019 [DependencyInjection] Add "instanceof" section for local interface-defined configs
This is a direction follow up of #21357 on which we're working together with @dunglas. From the description posted there:
There is some work being done to include features of DunglasActionBundle in the core of Symfony. The goal of all those PRs is to improve the developper experience of the framework, allow to develop faster while preserving all benefits of using Symfony (strictness, modularity, extensibility...) and make it easier to learn for newcomers.
This PR implements the tagging feature of ActionBundle in a more generic way. It will help to get rid of
AppBundlein the the standard edition and to register automatically some classes including commands.Here is an example of config (that can be embedded in the standard edition) to enable those features:
It's part of our 0 config initiative: controllers and commands will be automatically registered as services and "autowired", allowing the user to create and inject new services without having to write a single line of YAML or XML.
When refactoring changes are also automatically updated and don't require to update config files. It's a big win for rapid application development and prototyping.
Of course, this is fully compatible with the actual way of defining services and it's possible to switch (or mix) approaches very easily. It's even possible to start prototyping using 0config features then switch to explicit services definitions when the project becomes mature.