diff --git a/service_container/3.3-di-changes.rst b/service_container/3.3-di-changes.rst index d299e0240ef..1a9faf97350 100644 --- a/service_container/3.3-di-changes.rst +++ b/service_container/3.3-di-changes.rst @@ -8,19 +8,19 @@ without sacrificing predictability, which is very important! Another goal is to controllers and services behave more consistently. In Symfony 3.3, controllers *are* services by default. -The documentation has already been updated to assume you have these new features enabled. -If you're an existing Symfony user and want to understand the "what" and "why" behind -these changes, this chapter is for you! +The documentation has already been updated to assume you have these new features +enabled. If you're an existing Symfony user and want to understand the "what" +and "why" behind these changes, this article is for you! -All Changes are Opt-In ----------------------- +All Changes are Optional +------------------------ Most importantly, **you can upgrade to Symfony 3.3 today without making any changes to your app**. Symfony has a strict :doc:`backwards compatibility promise `, which means it's always safe to upgrade across minor versions. -All of the new features are **opt-in**: you need to actually change your configuration -files to use them. +All of the new features are **optional**: they are not enabled by default, so you +need to actually change your configuration files to use them. The new Default services.yml File --------------------------------- @@ -151,7 +151,7 @@ thanks to the following config: // services cannot be automatically loaded with PHP configuration // you need to define your services one-by-one -This means that every class in ``src/AppBundle`` is *available* to be used as a +This means that every class in ``src/AppBundle/`` is *available* to be used as a service. And thanks to the ``_defaults`` section at the top of the file, all of these services are **autowired** and **private** (i.e. ``public: false``). @@ -166,7 +166,7 @@ to determine most arguments automatically. But, you can always override the serv and :ref:`manually configure arguments ` or anything else special about your service. - But wait, if I have some model (non-service) classes in my ``src/AppBundle`` + But wait, if I have some model (non-service) classes in my ``src/AppBundle/`` directory, doesn't this mean that *they* will also be registered as services? Isn't that a problem? @@ -230,12 +230,12 @@ To pass the ``InvoiceGenerator`` as an argument to ``InvoiceMailer``, you needed to specify the service's *id* as an argument: ``app.invoice_generator``. Service id's were the main way that you configured things. -But in Symfony 3.3, thanks to autowiring, all you need to do is type-hint the argument -with ``InvoiceGenerator``:: +But in Symfony 3.3, thanks to autowiring, all you need to do is type-hint the +argument with ``InvoiceGenerator``:: // src/AppBundle/Service/InvoiceMailer.php // ... - + class InvoiceMailer { private $generator; @@ -288,7 +288,7 @@ was designed with that in mind. Specifically: a service whose id matches the type-hint exactly. It does *not* scan all services looking for objects that have that class/interface (actually, it *does* do this in Symfony 3.3, but has been deprecated. If you rely on this, you will see a clear - deprecation warning). + deprecation warning). Autowiring aims to *automate* configuration without magic. @@ -387,7 +387,7 @@ create the class:: // src/AppBundle/EventSubscriber/SetHeaderSusbcriber.php // ... - + use Symfony\Component\EventDispatcher\EventSubscriberInterface; use Symfony\Component\HttpKernel\Event\FilterResponseEvent; use Symfony\Component\HttpKernel\KernelEvents; @@ -398,7 +398,7 @@ create the class:: { $event->getResponse()->headers->set('X-SYMFONY-3.3', 'Less config'); } - + public static function getSubscribedEvents() { return [ @@ -499,8 +499,8 @@ Start by adding a ``_defaults`` section with ``autowire`` and ``autoconfigure``. # ... This step is easy: you're already *explicitly* configuring all of your services. -So, ``autowire`` does nothing. You're also already tagging your services, so ``autoconfigure`` -also doesn't change any existing services. +So, ``autowire`` does nothing. You're also already tagging your services, so +``autoconfigure`` also doesn't change any existing services. You have not added ``public: false`` yet. That will come in a minute. @@ -574,7 +574,7 @@ Now you're ready to default all services to be private: # app/config/services.yml # ... - + services: _defaults: autowire: true @@ -592,7 +592,7 @@ instances of the same class), you may need to make those public: # app/config/services.yml # ... - + services: # ... @@ -602,7 +602,7 @@ instances of the same class), you may need to make those public: + # remove this if/when you are not fetching this + # directly from the container via $container->get() + public: true - + app.api_client_sl_connect: # ... + public: true @@ -614,8 +614,8 @@ clean that up. Step 4) Auto-registering Services ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -You're now ready to automatically register all services in ``src/AppBundle`` (and/or -any other directory/bundle you have): +You're now ready to automatically register all services in ``src/AppBundle/`` +(and/or any other directory/bundle you have): .. code-block:: diff @@ -697,7 +697,7 @@ these directly from the container, you can remove the ``public: true`` flag: app.api_client_github: # ... - public: true - + app.api_client_sl_connect: # ... - public: true