Configuring DI Container
************************

.[perex]
Overview of configuration options for the Nette DI container.


Configuration File
==================

Nette DI container is easy to control using configuration files. They are usually written in [NEON format|neon:format]. We recommend to use [editors with support|best-practices:editors-and-tools#ide-editor] for this format for editing.

<pre>
"decorator .[prism-token prism-atrule]":[#Decorator]: 	"Decorator .[prism-token prism-comment]"<br>
"di .[prism-token prism-atrule]":[#DI]: 			"DI Container .[prism-token prism-comment]"<br>
"extensions .[prism-token prism-atrule]":[#Extensions]: 	"Install additional DI extensions .[prism-token prism-comment]"<br>
"includes .[prism-token prism-atrule]":[#Including files]: 	"Including files .[prism-token prism-comment]"<br>
"parameters .[prism-token prism-atrule]":[#Parameters]: 	"Parameters .[prism-token prism-comment]"<br>
"search .[prism-token prism-atrule]":[#Search]: 		"Automatic service registration .[prism-token prism-comment]"<br>
"services .[prism-token prism-atrule]":[services]: 		"Services .[prism-token prism-comment]"
</pre>

To write a string containing the character `%`, you must escape it by doubling it to `%%`. .[note]


Parameters
==========

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.

```neon
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 strings like `'%wwwDir%/images'`.

Parameters do not need to be just strings, they can also be array values:

```neon
parameters:
	mailer:
		host: smtp.example.com
		secure: ssl
		user: franta@gmail.com
	languages: [cs, en, de]
```

You can refer to single key as `%mailer.user%`.

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.


Services
========

See [separate chapter|services].


Decorator
=========

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.

```neon
decorator:
	# for all services that are instances of this class or interface
	App\UI\BasePresenter:
		setup:
			- setProjectId(10)       # call this method
			- $absoluteUrls = true   # and set the variable
```

Decorator can also be used to set [tags|services#Tags] or turn on [inject mode|services#Inject Mode].

```neon
decorator:
	InjectableInterface:
		tags: [mytag: 1]
		inject: true
```


DI
===

Technical settings of the DI container.

```neon
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
```


Metadata Export
---------------

The DI container class also contains a lot of metadata. You can reduce it by reducing the metadata export.

```neon
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->getParameters()` 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 `false`.

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 [application:bootstrap] to get `Nette\Application\Application`), you can disable the export entirely with `false`.


Extensions
==========

Registration of other DI extensions. In this way we add, for example, DI extension `Dibi\Bridges\Nette\DibiExtension22` under the name `dibi`:

```neon
extensions:
	dibi: Dibi\Bridges\Nette\DibiExtension22
```

Then we configure it in it's section called also `dibi`:

```neon
dibi:
	host: localhost
```

You can also add a extension class with parameters:

```neon
extensions:
	application: Nette\Bridges\ApplicationDI\ApplicationExtension(%debugMode%, %appDir%, %tempDir%/cache)
```


Including Files
===============

Additional configuration files can be inserted in the `includes` section:

```neon
includes:
	- parameters.php
	- services.neon
	- presenters.neon
```

The name `parameters.php` is not a typo, the configuration can also be written in a PHP file, which returns it as an array:

```php
<?php
return [
	'database' => [
		'main' => [
			'dsn' => 'sqlite::memory:',
		],
	],
];
```

If items with the same keys appear within configuration files, they will be [overwritten or merged |#Merging] in the case of arrays. Later included file has a higher priority than the previous one. The file in which the `includes` section is listed has a higher priority than the files included in it.


Search
======

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:

```neon
search:
	-	in: %appDir%/Forms
	-	in: %appDir%/Model
```

Usually, however, we don't want to add all the classes and interfaces, so we can filter them:

```neon
search:
	-	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:


```neon
search:
	-	in: %appDir%
		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:

```neon
search:
	-	in: %appDir%
		exclude:
			files: ...
			classes: ...
			extends: ...
			implements: ...
```

Tags can be set for added services:

```neon
search:
	-	in: %appDir%
		tags: ...
```


Merging
=======

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.

<table class=table>
<tr>
	<th width=33%>config1.neon</th>
	<th width=33%>config2.neon</th>
	<th>result</th>
</tr>
<tr>
	<td>
```neon
items:
	- 1
	- 2
```
	</td>
	<td>
```neon
items:
	- 3
```
	</td>
	<td>
```neon
items:
	- 1
	- 2
	- 3
```
	</td>
</tr>
</table>

To prevent merging of a certain array use exclamation mark right after the name of the array:

<table class=table>
<tr>
	<th width=33%>config1.neon</th>
	<th width=33%>config2.neon</th>
	<th>result</th>
</tr>
<tr>
	<td>
```neon
items:
	- 1
	- 2
```
	</td>
	<td>
```neon
items!:
	- 3
```
	</td>
	<td>
```neon
items:
	- 3
```
	</td>
</tr>
</table>


{{maintitle: Dependency Injection Configuration}}