In Symfony 3.3, configuring services is much simpler thanks to these new configuration options:
_defaults
: defines the default value for thepublic
,tags
andautowire
options of the services defined in a given file;_instanceof
: defines the default configuration of services depending on their classes (e.g. add thetwig.extension
tag to any service that implementsTwig_ExtensionInterface
).
The evolution of this simplification is the new autoconfigure
option, which
is like an automated version of _instanceof
. If enabled, this option adds
some default configuration depending on the class implemented by the service.
Let's suppose that you want to add tags automatically to your security voters:
1 2 3 4 5 6 7 8 9
services:
_defaults:
autowire: true
_instanceof:
Symfony\Component\Security\Core\Authorization\Voter\VoterInterface:
tags: [security.voter]
AppBundle\Security\PostVoter: ~
Now ask yourself: if you are registering a service with a class that implements
VoterInterface
, when would you ever not want that to be tagged with
security.voter
? In other words, a service implementing VoterInterface
can only be a security voter, unless you are doing some seriously weird things.
The same example using autoconfigure
looks like this:
1 2 3 4 5 6
services:
_defaults:
autowire: true
autoconfigure: true
AppBundle\Security\PostVoter: ~
This works because each enabled bundle has the opportunity to add one or more
automated _instanceof
definitions. Of course we've already enabled this for
all the common Symfony services: commands, form types, event subscribers, etc.
It's not magic
Whenever we introduce a new feature to automatize the configuration of services, some developers quickly discredit it for being "magic". For us, "magic" means that something happened without you explicitly asking for it. Magic is bad because it leads to WTF moments and hard-to-debug issues.
However, this feature won't work unless you explicitly include the
autoconfigure
option in your configuration file. Besides, it only applies
to the services defined in the same file where you include autoconfigure
,
so there will be no side-effects. In short, this is not magic, just automation.
s/_instaceof/_instanceof/ :)
@Titouan fixed! Thanks.
Just wondering, is there a case where you don't need
autoconfigure: true
by default?@Tomas that WOULD make it magic.
@Javier the last section would really benefit from some explanation on how this non-magic is happened, ie. how does Symfony know what to do with a VoterInterface.
@Niels the "how it works" is briefly explained in this paragraph:
"This works because each enabled bundle has the opportunity to add one or more automated _instanceof definitions. Of course we've already enabled this for all the common Symfony services: commands, form types, event subscribers, etc."
@Niels Keurentjes THIS IS MAGIC. It's already double magic actually with adding tags and they're auto-adding just to refer and interface.
This has no added value for end user at the moment, since instead of "tags: sth" I just write global per-file "autoconfigure". I even had to go to PR to find out what this word stands for this, since "autoconfigure" tell me the same none information as "automanager".
All it does is this:
$collector = new Collector; foreach ($containerBuilder->findByType(Collected::class) as $collected) { $collector->addCollected($collected); }
Nothing more. There is a lot code and huge complexity around this, for reasons that rather allow bad architecture designs then help to write robust and solid code.
Btw, how can I highlight code here? :D I broke the indentation :(
@Tomáš sorry, no highlighting of pretty formatting in blog comments.
@Javier: Too bad. Would be really handy on PHP website.
Great job with PSR-4 autodiscovery feature, btw! Finally can drop my bundle :) Did I miss a post about that?
@Tomáš it's hidden in http://symfony.com/blog/new-in-symfony-3-3-simpler-service-configuration