-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Docs for referencing tagged services in config #8404
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.
Thanks for writing the docs @ro0NL! I've left some comments, can you have a look at them (feel free to change or comment on all my suggestions)
service_container/tags.rst
Outdated
@@ -405,3 +405,92 @@ The double loop may be confusing. This is because a service can have more | |||
than one tag. You tag a service twice or more with the ``app.mail_transport`` | |||
tag. The second foreach loop iterates over the ``app.mail_transport`` | |||
tags set for the current service and gives you the attributes. | |||
|
|||
Reference tagged services |
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.
"Reference Tagged Services" (title case uppercases almost every word, except when there are closed words)
service_container/tags.rst
Outdated
|
||
ThereBecause this task is so generic and common to do, Symfony provides a way to achieve this | ||
directly in your service container confguration. This enables to inject services tagged | ||
with e.g. `app.handler` into another service that collects all handlers. |
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.
Inline code blocks should be surrounded by double backticks (single backticks are used for references)
service_container/tags.rst
Outdated
tags: [app.handler] | ||
|
||
App\HandlerCollection: | ||
arguments: [!tagged app.handler] |
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.
Let's put a comment here describing that this is passing all services tagged with app.handler
as an array argument to this class. (Same for the other formats)
service_container/tags.rst
Outdated
public function __construct(iterable $handlers) | ||
{ | ||
} | ||
} |
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.
This block should be moved 4 spaces to the left (the .. code-block:: php
part should be in column 0)
service_container/tags.rst
Outdated
- { name: app.handler, priority: 20 } | ||
|
||
.. versionadded:: 3.4 | ||
|
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.
This line should be removed (versionadded is a really strange directive). And let's move this to just below the section title
service_container/tags.rst
Outdated
In case your tag doesn't require any further additional attributes writing compiler | ||
passes per tag might become tedious. A way to overcome this is is to make your compiler | ||
pass more generic. The downside of this approach is you have to write and maintain | ||
additional code, considering you want to reuse it over multiple projects. |
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 think we need so much information and we're kinda missing the complete feature here: Using tags to inject a list of services to another service. Tags can do non-injecting stuff as well. What about saying something like: (change at your free will 😄 )
If you use tags to inject a list of services as an argument, writing a compiler pass is a bit tedious. As this is a very common case, Symfony provides a way to inject all services tagged with a specific tag. The downside of this feature is that you can't have any custom attributes. In the example below, all services tagged with
app.handler
are passed in an array as the first constructor argument to theApp\\HandlerCollection
service:
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.
agree. this text is good as a blog post introducing this new feature as it explains the thought process. but it does not fit as a feature documention
This PR was merged into the 3.4 branch. Discussion ---------- [DI] Reference tagged services in config | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #12269 | License | MIT | Doc PR | symfony/symfony-docs#8404 This is a proof of concept to reference a sequence of tagged services. The problem bugs me for some time, and at first i thought the solution was to have some super generic compiler pass. If it could replace a lot of compilers in core.. perhaps worth it, but eventually each tag comes with it's own logic, including how to deal with tag attributes. However, writing the passes over and over again becomes tedious for the most basic usecase. So given the recent developments, this idea came to mind. ```yml services: a: class: stdClass properties: { a: true } tags: [foo] b: class: stdClass properties: { b: true } tags: [foo] c: class: stdClass properties: #stds: !tagged_services foo (see #22198) stds: !tagged_services foo ``` ``` dump(iterator_to_array($this->get('c')->stds)); ``` ``` array:2 [▼ 0 => {#5052 ▼ +"a": true } 1 => {#4667 ▼ +"b": true } ] ``` Given the _basic_ example at https://symfony.com/doc/current/service_container/tags.html, this could replace that. Any thoughts? Commits ------- 979e58f [DI] Reference tagged services in config
This PR was merged into the 3.4 branch. Discussion ---------- [DI] Reference tagged services in config | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #12269 | License | MIT | Doc PR | symfony/symfony-docs#8404 This is a proof of concept to reference a sequence of tagged services. The problem bugs me for some time, and at first i thought the solution was to have some super generic compiler pass. If it could replace a lot of compilers in core.. perhaps worth it, but eventually each tag comes with it's own logic, including how to deal with tag attributes. However, writing the passes over and over again becomes tedious for the most basic usecase. So given the recent developments, this idea came to mind. ```yml services: a: class: stdClass properties: { a: true } tags: [foo] b: class: stdClass properties: { b: true } tags: [foo] c: class: stdClass properties: #stds: !tagged_services foo (see #22198) stds: !tagged_services foo ``` ``` dump(iterator_to_array($this->get('c')->stds)); ``` ``` array:2 [▼ 0 => {#5052 ▼ +"a": true } 1 => {#4667 ▼ +"b": true } ] ``` Given the _basic_ example at https://symfony.com/doc/current/service_container/tags.html, this could replace that. Any thoughts? Commits ------- 979e58f [DI] Reference tagged services in config
This PR was merged into the 3.4 branch. Discussion ---------- [DI] Reference tagged services in config | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #12269 | License | MIT | Doc PR | symfony/symfony-docs#8404 This is a proof of concept to reference a sequence of tagged services. The problem bugs me for some time, and at first i thought the solution was to have some super generic compiler pass. If it could replace a lot of compilers in core.. perhaps worth it, but eventually each tag comes with it's own logic, including how to deal with tag attributes. However, writing the passes over and over again becomes tedious for the most basic usecase. So given the recent developments, this idea came to mind. ```yml services: a: class: stdClass properties: { a: true } tags: [foo] b: class: stdClass properties: { b: true } tags: [foo] c: class: stdClass properties: #stds: !tagged_services foo (see #22198) stds: !tagged_services foo ``` ``` dump(iterator_to_array($this->get('c')->stds)); ``` ``` array:2 [▼ 0 => {#5052 ▼ +"a": true } 1 => {#4667 ▼ +"b": true } ] ``` Given the _basic_ example at https://symfony.com/doc/current/service_container/tags.html, this could replace that. Any thoughts? Commits ------- 979e58f [DI] Reference tagged services in config
ping @wouterj comments addressed :) |
IMO it should be mentioned the passed iterable is a generator that loads each service lazily when iterating. |
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.
Looks good!
service_container/tags.rst
Outdated
~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
||
.. versionadded:: 3.4 | ||
|
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.
This empty line should be removed, otherwise the directive doesn't work (versionadded is weird)
service_container/tags.rst
Outdated
|
||
The downside of this feature is that you can't have any custom attributes. In the | ||
example below, all services tagged with ``app.handler`` are passed as first | ||
constructor argument to the ``App\HandlerCollection`` service: |
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'll have to look at platformsh, but I think we need a double \\
here.
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 have a question about this phrase:
The only downside of this feature is that you can't
have any custom attributes.
Could you please explain a bit more what does it mean? Thanks!
Agree. You can have them, however you cant leverage them with this specific feature. That needs to be clarified yes. Status: needs work |
service_container/tags.rst
Outdated
|
||
The collected services can be prioritized using the ``priority`` attribute. | ||
|
||
.. code-block:: yaml |
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 are missing XML and PHP examples. :)
service_container/tags.rst
Outdated
|
||
.. tip:: | ||
|
||
The collected services can be prioritized using the ``priority`` attribute. |
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.
the sentence could end with a colon
service_container/tags.rst
Outdated
$container->register(\App\Handler\Two::class) | ||
->addTag('app.handler'); | ||
|
||
$container->register(\App\HandlerCollection::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.
the leading backslash should be removed eveyrwhere
service_container/tags.rst
Outdated
|
||
.. code-block:: yaml | ||
|
||
services: |
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 filename comment (same for the other formats):
# app/config/services.yml
Last commit 2e5c87f addresses @javiereguiluz comment. |
service_container/tags.rst
Outdated
->addTag('app.handler', array('priority' => 20)); | ||
|
||
Note that any other custom attributes will be ignored by this feature. | ||
|
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.
trailing blank line should be removed
service_container/tags.rst
Outdated
|
||
# app/config/services.yml | ||
services: | ||
App\Handler\One: |
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 think we should still use examples from the AppBundle
namespace
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.
That's right. We'll remove AppBundle in 4.0, but we must still use it in 3.4.
service_container/tags.rst
Outdated
|
||
.. code-block:: php | ||
|
||
class HandlerCollection |
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 namespace and filename comment
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 just left a few minor comments, but apart from that this looks good to me.
Thank you @ro0NL. |
…javiereguiluz) This PR was merged into the 3.4 branch. Discussion ---------- Docs for referencing tagged services in config See symfony/symfony#22200 Curious how it looks :) also a bit related to #8403 Commits ------- ed70659 Update tags.rst 2e5c87f Update tags.rst 564b5ea Update tags.rst a2fd23f Update tags.rst 000b801 Minor reword and fixes 0aaf48b Update tags.rst 71158f8 Update tags.rst 61c74da Update tags.rst da034d2 Docs for referencing tagged services in config
See symfony/symfony#22200
Curious how it looks :) also a bit related to #8403