Skip to content

Reworded the explanation about service tags #8651

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

Merged
merged 2 commits into from
Nov 17, 2017
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 13 additions & 12 deletions service_container/tags.rst
Original file line number Diff line number Diff line change
Expand Up @@ -5,10 +5,15 @@
How to Work with Service Tags
=============================

In the same way that a blog post on the web might be tagged with things such
as "Symfony" or "PHP", services configured in your container can also be
tagged. In the service container, a tag implies that the service is meant
to be used for a specific purpose. Take the following example:
Some container services require to be registered or used in some special way.
Consider for example the :doc:`Twig extensions </templating/twig_extension>`:
they are PHP classes that must be added to the main Twig object before using
them. If you define those exensions as regular Symfony services, Twig will
ignore them and an exception will be thrown when using them in templates.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually like your second paragraph a lot... and I think we should only have it, and remove the first paragraph completely. wdyt?


**Service tags** are a way to tell Symfony or other third-party bundles that
your service should be registered in some special way. Take the following
example:

.. configuration-block::

Expand Down Expand Up @@ -51,14 +56,10 @@ to be used for a specific purpose. Take the following example:
->setPublic(false)
->addTag('twig.extension');

The ``twig.extension`` tag is a special tag that the TwigBundle uses
during configuration. By giving the service this ``twig.extension`` tag,
the bundle knows that the ``app.twig_extension`` service should be registered
as a Twig extension with Twig. In other words, Twig finds all services tagged
with ``twig.extension`` and automatically registers them as extensions.

Tags, then, are a way to tell Symfony or other third-party bundles that
your service should be registered or used in some special way by the bundle.
Services tagged with the ``twig.extension`` tag are collected during the
initialization of TwigBundle to enable them as Twig extensions. In this example,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about?

... TwigBundle and added to Twig as extensions.

that's why Symfony knows that the ``app.twig_extension`` service should be
registered as a Twig extension.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced this last sentence adds any value.

A total alternative, could be:

Other tags are used to integrate your services into other systems.

(actually, this could be the first sentence of the next paragraph)


For a list of all the tags available in the core Symfony Framework, check
out :doc:`/reference/dic_tags`. Each of these has a different effect on your
Expand Down