-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Updates to DI config for 3.3 #7807
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
Changes from 1 commit
8433fc1
2d11347
105801c
049df7d
9e84572
c45daf4
2636bea
9ab27f0
0e48bd8
6e6ed94
70178d1
45500b3
759e9b2
6de83e2
89e12de
443aec2
bc7088d
ee27765
5452c61
2229fd3
cac3c6c
12c4944
22adfbd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -25,7 +25,7 @@ Fetching and using Services | |
|
||
The moment you start a Symfony app, your container *already* contains many services. | ||
These are like *tools*, waiting for you to take advantage of them. In your controller, | ||
you can "ask" for a service from the container by type-hinting an argument wit the | ||
you can "ask" for a service from the container by type-hinting an argument with the | ||
service's class or interface name. Want to :doc:`log </logging>` something? No problem:: | ||
|
||
// src/AppBundle/Controller/ProductController.php | ||
|
@@ -155,7 +155,7 @@ the service container *how* to instantiate it: | |
|
||
# loads services from whatever directories you want (you can update this!) | ||
AppBundle\: | ||
resource: '../../src/AppBundle/{Service,EventDispatcher,Twig,Form}' | ||
resource: '../../src/AppBundle/{Service,Command,Form,EventSubscriber,Twig,Security}' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. sorry for being late, but what about giving an absolute path here with AppBundle\:
# glob with path relative to this file
resource: '../../src/AppBundle/{Service,Command,Form,EventSubscriber,Twig,Security}'
# or
resource: '%kernel.root_path%/../../src/AppBundle/{Service,Command,Form,EventSubscriber,Twig,Security}' The case above may not be a good one since it makes it extra verbose, but I've seen quite a few projects where they are using a custom parameter to point to Also I don't see anywhere mentioned that it's a glob that's being used. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Even better, I forgot we were adding this in 3.3! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see a big gain, that makes one more thing to learn for newcomers while relative paths are understandable by everyone. |
||
|
||
.. code-block:: xml | ||
|
||
|
@@ -171,14 +171,20 @@ the service container *how* to instantiate it: | |
<defaults autowire="true" autoconfigure="true" public="false" /> | ||
|
||
<!-- Load services from whatever directories you want (you can update this!) --> | ||
<prototype namespace="AppBundle\" resource="../../src/AppBundle/{Service,EventDispatcher,Twig,Form}" /> | ||
<prototype namespace="AppBundle\" resource="../../src/AppBundle/{Service,Command,Form,EventSubscriber,Twig,Security}" /> | ||
</services> | ||
</container> | ||
|
||
.. code-block:: php | ||
|
||
// app/config/services.php | ||
// _defaults and loading entire directories is not possible with PHP configuration | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would keep a concrete example here for those who really want to use php: // you have to define your services one-by-one
use AppBundle/Service/MessageGenerator;
$container->autowire(MessageGenerator::class)
->setAutoconfigured(true)
->setPublic(false); |
||
// you need to define your servicess one-by-one | ||
use AppBundle/Service/MessageGenerator; | ||
|
||
$container->autowire(MessageGenerator::class) | ||
->setAutoconfigured(true) | ||
->setPublic(false); | ||
|
||
.. versionadded:: 3.3 | ||
The ``_defaults`` key and ability to load services from a directory were added | ||
|
@@ -228,18 +234,20 @@ be its class name in this case:: | |
} | ||
} | ||
|
||
However, this only works if you set your service to be :ref:`public <container-public>`. | ||
However, this only works if you make your service :ref:`public <container-public>`. | ||
|
||
.. caution:: | ||
|
||
Service ids are case-insensitive (e.g. ``AppBundle\Service\MessageGenerator`` | ||
and ``appbundle\service\messagegenerator`` refer to the same service). But this | ||
was deprecated in Symfony 3.3. Starting in 4.0, service ids will be case sensitive. | ||
|
||
.. _services-constructor-injection: | ||
|
||
Injecting Services/Config into a Service | ||
---------------------------------------- | ||
|
||
What if need to access the ``logger`` service from within ``MessageGenerator``? | ||
What if you need to access the ``logger`` service from within ``MessageGenerator``? | ||
Your service does *not* have access to the container directly, so you can't fetch | ||
it via ``$this->container->get()``. | ||
|
||
|
@@ -272,17 +280,17 @@ when instantiating the ``MessageGenerator``. How does it know to do this? | |
:doc:`Autowiring </service_container/autowiring>`. The key is the ``LoggerInterface`` | ||
type-hint in your ``__construct()`` method and the ``autowire: true`` config in | ||
``services.yml``. When you type-hint an argument, the container will automatically | ||
find the matching service. If it can't or there is any ambiguity, you'll see a clear | ||
exception with a helpful suggestion. | ||
find the matching service. If it can't, you'll see a clear exception with a helpful | ||
suggestion. | ||
|
||
Be sure to read more about :doc:`autowiring </service_container/autowiring>`. | ||
|
||
.. tip:: | ||
|
||
How should you know to use ``LoggerInterface`` for the type-hint? The best way | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. there must be an alias for it (see previous comment) |
||
is by reading the docs for whatever feature you're using. You can also use the | ||
``php bin/console debug:container`` console command to get a hint | ||
to the class name for a service. | ||
``php bin/console debug:container --types`` console command to get a list of | ||
available type-hints. | ||
|
||
Handling Multiple Services | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
@@ -337,7 +345,7 @@ the new ``Updates`` sub-directory: | |
|
||
# registers all classes in Services & Updates directories | ||
AppBundle\: | ||
resource: '../../src/AppBundle/{Service,Updates,EventDispatcher,Twig,Form}' | ||
resource: '../../src/AppBundle/{Service,Updates,Command,Form,EventSubscriber,Twig,Security}' | ||
|
||
.. code-block:: xml | ||
|
||
|
@@ -352,7 +360,7 @@ the new ``Updates`` sub-directory: | |
<!-- ... --> | ||
|
||
<!-- Registers all classes in Services & Updates directories --> | ||
<prototype namespace="AppBundle\" resource="../../src/AppBundle/{Service,Updates,EventDispatcher,Twig,Form}" /> | ||
<prototype namespace="AppBundle\" resource="../../src/AppBundle/{Service,Updates,Command,Form,EventSubscriber,Twig,Security}" /> | ||
</services> | ||
</container> | ||
|
||
|
@@ -370,7 +378,7 @@ Now, you can use the service immediately:: | |
} | ||
|
||
Thanks to autowiring and your type-hints in ``__construct()``, the container creates | ||
the ``SiteUpdateManager`` object and passes it the correct arguments. In most cases, | ||
the ``SiteUpdateManager`` object and passes it the correct argument. In most cases, | ||
this works perfectly. | ||
|
||
Manually Wiring Arguments | ||
|
@@ -428,7 +436,7 @@ pass here. No problem! In your configuration, you can explicitly set this argume | |
|
||
# same as before | ||
AppBundle\: | ||
resource: '../../src/AppBundle/{Service,Updates}' | ||
resource: '../../src/AppBundle/{Service,Updates,Command,Form,EventSubscriber,Twig,Security}' | ||
|
||
# explicitly configure the service | ||
AppBundle\Updates\SiteUpdateManager: | ||
|
@@ -448,7 +456,7 @@ pass here. No problem! In your configuration, you can explicitly set this argume | |
<!-- ... --> | ||
|
||
<!-- Same as before --> | ||
<prototype namespace="AppBundle\" resource="../../src/AppBundle/{Service,Updates}" /> | ||
<prototype namespace="AppBundle\" resource="../../src/AppBundle/{Service,Updates,Command,Form,EventSubscriber,Twig,Security}" /> | ||
|
||
<!-- Explicitly configure the service --> | ||
<service id="AppBundle\Updates\SiteUpdateManager"> | ||
|
@@ -526,6 +534,8 @@ and reference it with the ``%parameter_name%`` syntax: | |
|
||
.. code-block:: php | ||
|
||
// app/config/services.php | ||
use AppBundle\Updates\SiteUpdateManager; | ||
$container->setParameter('admin_email', 'manager@example.com'); | ||
|
||
$container->autowire(SiteUpdateManager::class) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. missing use statement |
||
|
@@ -659,7 +669,7 @@ The autoconfigure Option | |
Above, we've set ``autoconfigure: true`` in the ``_defaults`` section so that it | ||
applies to all services defined in that file. With this setting, the container will | ||
automatically apply certain configuration to your services, based on your service's | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
*class*. The is mostly used to *auto-tag* your services. | ||
*class*. This is mostly used to *auto-tag* your services. | ||
|
||
For example, to create a Twig Extension, you need to create a class, register it | ||
as a service, and :doc:`tag </service_container/tags>` it with ``twig.extension``: | ||
|
@@ -702,7 +712,8 @@ as a service, and :doc:`tag </service_container/tags>` it with ``twig.extension` | |
->addTag('twig.extension'); | ||
|
||
But, with ``autoconfigure: true``, you don't need the tag. In fact, all you need | ||
to do is load your service from the ``Twig`` directory: | ||
to do is load your service from the ``Twig`` directory, which is already loaded | ||
by default in a fresh Symfony install: | ||
|
||
.. configuration-block:: | ||
|
||
|
@@ -716,7 +727,7 @@ to do is load your service from the ``Twig`` directory: | |
|
||
# load your services from the Twig directory | ||
AppBundle\: | ||
resource: '../../src/AppBundle/{Service,EventDispatcher,Twig,Form}' | ||
resource: '../../src/AppBundle/{Service,Updates,Command,Form,EventSubscriber,Twig,Security}' | ||
|
||
.. code-block:: xml | ||
|
||
|
@@ -731,7 +742,7 @@ to do is load your service from the ``Twig`` directory: | |
<defaults autowire="true" autoconfigure="true" /> | ||
|
||
<!-- Load your services--> | ||
<prototype namespace="AppBundle\" resource="../../src/AppBundle/{Service,EventDispatcher,Twig,Form}" /> | ||
<prototype namespace="AppBundle\" resource="../../src/AppBundle/{Service,Updates,Command,Form,EventSubscriber,Twig,Security}" /> | ||
</services> | ||
</container> | ||
|
||
|
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 will render the error message as a block quote. Do we really want that? I suggest to use a
text
code block instead.