Configuring DI Container
Overview of configuration options for the Nette DI container.
di: DI Container
extensions: Install additional DI extensions
includes: Including files
search: Automatic service registration
If you use a string that starts with
@ or has
% anywhere in it, you need to escape it by
You can define parameters that can then be used as part of service definitions. This can help to separate out values that you will want to change more regularly.
parameters: dsn: 'mysql:host=127.0.0.1;dbname=test' user: root password: secret
You can refer to
foo parameter via
%foo% elsewhere in any config file. They can also be used inside
Parameters do not need to be just strings, they can also be array values:
parameters: mailer: host: smtp.example.com secure: ssl user: firstname.lastname@example.org languages: [cs, en, de]
You can refer to single key as
If you need to get the value of any parameter in your code, for example in your class, then pass it to this class. For example, in the constructor. There is no global configuration object which can classes query for parameter values. This would be against to the principle of dependency injection.
See separate chapter.
How to bulk edit all services of a certain type? Need to call a certain method for all presenters inheriting from a particular common ancestor? That's where the decorator comes from.
decorator: # for all services that are instances of this class or interface App\Presenters\BasePresenter: setup: - setProjectId(10) # call this method - $absoluteUrls = true # and set the variable
decorator: InjectableInterface: tags: [mytag: 1] inject: true
Technical settings of the DI container.
di: # shows DIC in Tracy Bar? debugger: ... # (bool) defaults to true # parameter types that you never autowire excluded: ... # (string) # the class from which the DI container inherits parentClass: ... # (string) defaults to Nette\DI\Container
The DI container class also contains a lot of metadata. You can reduce it by reducing the metadata export.
di: export: # to export parameters? parameters: false # (bool) defaults to true # export tags and which ones? tags: # (string|bool) the default is all - event.subscriber # export data for autowiring and which? types: # (string|bool) the default is all - Nette\Database\Connection - Symfony\Component\Console\Application
If you don't use the
$container->parameters array, you can disable parameter export. Furthermore, you can
export only those tags through which you get services using the
$container->findByTag(...) method. If you don't
call the method at all, you can completely disable tag export with
You can significantly reduce the metadata for autowiring by specifying the classes you use as a parameter to the
$container->getByType() method. And again, if you don't call the method at all (or only in bootstrap to get
Nette\Application\Application), you can disable the export
Registration of other DI extensions. In this way we add, for exammple, DI extension
Dibi\Bridges\Nette\DibiExtension22 under the name
extensions: dibi: Dibi\Bridges\Nette\DibiExtension22
Then we configure it in it's section called also
dibi: host: localhost
You can also add a extension class with parameters:
extensions: application: Nette\Bridges\ApplicationDI\ApplicationExtension(%debugMode%, %appDir%, %tempDir%/cache)
Additional configuration files can be inserted in the
includes: - parameters.php - services.neon - presenters.neon
parameters.php is not a typo, the configuration can also be written in a PHP file, which returns it as
<?php return [ 'database' => [ 'main' => [ 'dsn' => 'sqlite::memory:', ], ], ];
If items with the same keys appear within configuration files, they will be overwritten or merged in
the case of arrays. Later included file has a higher priority than the previous one. The file in which the
section is listed has a higher priority than the files included in it.
The automatic adding of services to the DI container makes work extremely pleasant. Nette automatically adds presenters to the container, but you can easily add any other classes.
Just specify in which directories (and subdirectories) the classes should be search for:
search: # you choose the section names yourself myForms: in: %appDir%/Forms model: in: %appDir%/Model
Usually, however, we don't want to add all the classes and interfaces, so we can filter them:
search: myForms: in: %appDir%/Forms # filtering by file name (string|string) files: - *Factory.php # filtering by class name (string|string) classes: - *Factory
Or we can select classes that inherit or implement at least one of the following classes:
search: myForms: extends: - App\*Form implements: - App\*FormInterface
You can also define negative rules, ie class name masks or ancestors and if they comply, the service will not be added to the DI container:
search: myForms: exclude: classes: ... extends: ... implements: ...
Tags can be set for added services:
search: myForms: tags: ...
If items with the same keys appear in more configuration files, they will be overwritten or merged in the case of arrays. The later included file has a higher priority.
To prevent merging of a certain array use exclamation mark right after the name of the array: