-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DependencyInjection] Add "instanceof" section for local interface-defined configs #21530
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
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.
reverted
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should document the type of the argument (what is inside the array ?)
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.
done
/** | ||
* @experimental in version 3.3 | ||
*/ | ||
public function getInstanceofConditionals() |
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.
we should document the returned type (an array of something, but what ?)
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.
done
24d8139
to
8f5a69d
Compare
} | ||
|
||
/** | ||
* Gets the definition templates to conditionally apply on the current definition, keyed by parent interface/class |
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.
Missing dot at the end.
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.
fixed
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))); |
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.
missing "
around the second %s
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.
fixed
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
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:
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.