Configurazione del container DI

Panoramica delle opzioni di configurazione per il container Nette DI.

File di configurazione

Il container Nette DI è facilmente controllabile tramite file di configurazione. Questi sono solitamente scritti nel formato NEON. Per la modifica, consigliamo editor con supporto per questo formato.

 decorator: 	Decorator
di: Container DI
extensions: Installazione di estensioni DI aggiuntive
includes: Inclusione di file
parameters: Parametri
search: Registrazione automatica dei servizi
services: Servizi

Per scrivere una stringa contenente il carattere %, è necessario escaparlo raddoppiandolo in %%.

Parametri

Nella configurazione puoi definire parametri che possono poi essere utilizzati come parte delle definizioni dei servizi. In questo modo puoi rendere la configurazione più chiara o unificare ed estrarre valori che cambieranno.

parameters:
	dsn: 'mysql:host=127.0.0.1;dbname=test'
	user: root
	password: secret

Ci riferiamo al parametro dsn ovunque nella configurazione scrivendo %dsn%. I parametri possono essere utilizzati anche all'interno di stringhe come '%wwwDir%/images'.

I parametri non devono essere solo stringhe o numeri, possono anche contenere array:

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

Ci riferiamo a una chiave specifica come %mailer.user%.

Se hai bisogno nel tuo codice, ad esempio in una classe, di conoscere il valore di un qualsiasi parametro, passalo a questa classe. Ad esempio nel costruttore. Non esiste un oggetto globale che rappresenti la configurazione, a cui le classi chiedono i valori dei parametri. Ciò violerebbe il principio di dependency injection.

Servizi

Vedi capitolo separato.

Decorator

Come modificare in blocco tutti i servizi di un certo tipo? Ad esempio, chiamare un certo metodo su tutti i presenter che ereditano da un antenato comune specifico? A questo serve il decorator.

decorator:
	# per tutti i servizi che sono istanze di questa classe o interfaccia
	App\Presentation\BasePresenter:
		setup:
			- setProjectId(10)       # chiama questo metodo
			- $absoluteUrls = true   # e imposta la variabile

Il decorator può essere utilizzato anche per impostare tag o attivare la modalità inject.

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

DI

Impostazioni tecniche del container DI.

di:
	# visualizzare DIC nella Tracy Bar?
	debugger: ...        # (bool) predefinito è true

	# tipi di parametri da non autowirare mai
	excluded: ...        # (string[])

	# consentire la creazione lazy dei servizi?
	lazy: ...            # (bool) predefinito è false

	# classe da cui eredita il container DI
	parentClass: ...     # (string) predefinito è Nette\DI\Container

Servizi lazy

L'impostazione lazy: true attiva la creazione lazy (differita) dei servizi. Ciò significa che i servizi non vengono effettivamente creati nel momento in cui li richiediamo dal container DI, ma solo al momento del loro primo utilizzo. Ciò può accelerare l'avvio dell'applicazione e ridurre l'utilizzo della memoria, poiché vengono creati solo i servizi effettivamente necessari nella richiesta corrente.

Per un servizio specifico, la creazione lazy può essere modificata.

Gli oggetti lazy possono essere utilizzati solo per classi utente, non per classi PHP interne. Richiede PHP 8.4 o successivo.

Esportazione metadati

La classe del container DI contiene anche molti metadati. Puoi ridurne le dimensioni riducendo l'esportazione dei metadati.

di:
	export:
		# esportare i parametri?
		parameters: false   # (bool) predefinito è true

		# esportare i tag e quali?
		tags:               # (string[]|bool) predefiniti sono tutti
			- event.subscriber

		# esportare i dati per l'autowiring e quali?
		types:              # (string[]|bool) predefiniti sono tutti
			- Nette\Database\Connection
			- Symfony\Component\Console\Application

Se non utilizzi l'array $container->getParameters(), puoi disattivare l'esportazione dei parametri. Inoltre, puoi esportare solo i tag tramite i quali ottieni i servizi con il metodo $container->findByTag(...). Se non chiami affatto il metodo, puoi disattivare completamente l'esportazione dei tag usando false.

Puoi ridurre significativamente i metadati per l'autowiring specificando le classi che usi come parametro del metodo $container->getByType(). E ancora, se non chiami affatto il metodo (o solo nel bootstrap per ottenere Nette\Application\Application), puoi disattivare completamente l'esportazione usando false.

Estensioni

Registrazione di estensioni DI aggiuntive. In questo modo aggiungiamo ad esempio l'estensione DI Dibi\Bridges\Nette\DibiExtension22 con il nome dibi

extensions:
	dibi: Dibi\Bridges\Nette\DibiExtension22

Successivamente, la configuriamo nella sezione dibi:

dibi:
	host: localhost

Come estensione si può aggiungere anche una classe che ha parametri:

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

Inclusione di file

Possiamo includere altri file di configurazione nella sezione includes:

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

Il nome parameters.php non è un errore di battitura, la configurazione può essere scritta anche in un file PHP, che la restituisce come array:

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

Se nei file di configurazione compaiono elementi con le stesse chiavi, verranno sovrascritti o, nel caso di array, uniti. Il file incluso successivamente ha una priorità maggiore rispetto al precedente. Il file in cui è specificata la sezione includes ha una priorità maggiore rispetto ai file inclusi al suo interno.

L'aggiunta automatica di servizi al container DI rende il lavoro estremamente piacevole. Nette aggiunge automaticamente i presenter al container, ma è possibile aggiungere facilmente anche qualsiasi altra classe.

Basta specificare in quali directory (e sottodirectory) cercare le classi:

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

Di solito, però, non vogliamo aggiungere assolutamente tutte le classi e le interfacce, quindi possiamo filtrarle:

search:
	-	in: %appDir%/Forms

		# filtraggio per nome file (string|string[])
		files:
			- *Factory.php

		# filtraggio per nome classe (string|string[])
		classes:
			- *Factory

Oppure possiamo selezionare classi che ereditano o implementano almeno una delle classi specificate:

search:
	-	in: %appDir%
		extends:
			- App\*Form
		implements:
			- App\*FormInterface

È possibile definire anche regole di esclusione, cioè maschere di nomi di classi o antenati ereditari, che se soddisfatte, il servizio non viene aggiunto al container DI:

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

A tutti i servizi possono essere assegnati tag:

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

Unione

Se in più file di configurazione compaiono elementi con le stesse chiavi, verranno sovrascritti o, nel caso di array, uniti. Il file incluso successivamente ha una priorità maggiore rispetto al precedente.

config1.neon config2.neon risultato
items:
	- 1
	- 2
items:
	- 3
items:
	- 1
	- 2
	- 3

Per gli array, è possibile impedire l'unione specificando un punto esclamativo dopo il nome della chiave:

config1.neon config2.neon risultato
items:
	- 1
	- 2
items!:
	- 3
items:
	- 3
versione: 3.x