I tag della dependency injection

I tag della dependency injection sono piccole stringhe, che si possono applicare a un servizio per “marcarlo” per essere usato in un modo speciale. Per esempio, se si ha un servizio che si vuole registrare come ascoltatore di uno degli eventi del nucleo di Symfony, lo si può marcare con il tag kernel.event_listener.

Si possono approfondire i tag leggendo la sezione “I tag” del capitolo sul contenitore di servizi.

Di seguito si trovano informazioni su tutti i tag disponibili in Symfony. Potrebbero esserci altri tag in alcuni bundle utilizzati, che non sono elencati qui.

Nome tag Utilizzo
assetic.asset Registrare una risorsa nel gestore di risorse corrente
assetic.factory_worker Aggiungere un factory worker
assetic.filter Registrare un filtro
assetic.formula_loader Aggiungere un formula loader al gestore di risorse corrente
assetic.formula_resource Aggiungere una risorsa al gestore di risorse corrente
assetic.templating.php Rimuovere questo servizio se i template PHP sono disabilitati
assetic.templating.twig Rimuovere questo servizio se i template Twig sono disabilitati
console.command Aggiunge un comando
data_collector Creare una classe che raccolga dati personalizzati per il profilatore
doctrine.event_listener Aggiungere un ascoltatore di eventi Doctrine
doctrine.event_subscriber Aggiungere un sottoscrittore di eventi Doctrine
form.type Creare un tipo di campo personalizzato per i form
form.type_extension Creare un “form extension” personalizzato
form.type_guesser Aggiungere logica per “form type guessing”
kernel.cache_clearer Registrare un servizio da richiamare durante la pulizia della cache
kernel.cache_warmer Registrare un servizio da richiamare durante il cache warming
kernel.event_listener Ascoltare diversi eventi/agganci in Symfony
kernel.event_subscriber Sottoscrivere un insieme di vari eventi/agganci in Symfony
kernel.fragment_renderer Aggiunta di nuove strategie di resa del contenuto HTTP
monolog.logger Log con un canale di log personalizzato
monolog.processor Aggiunta di un processore personalizzato per i log
routing.loader Registrare un servizio personalizzato che carica rotte
security.voter Aggiunta di un votante alla logica di autorizzazione di Symfony
security.remember_me_aware Consentire il “ricorami” nell’autenticazione
serializer.encoder Registrare un nuovo codificatore nel servizio serializer
serializer.normalizer Registrare un nuovo normalizzatore nel servizio serializer
swiftmailer.plugin Registrare un plugin di SwiftMailer
templating.helper Rendere il servizio disponibile nei template PHP
translation.loader Registrare un servizio che carica traduzioni
translation.extractor Registrare un servizio personalizzato che estrae messaggi di traduzione
translation.dumper Registrare un servizio personalizzato che esporta messaggi di traduzione
twig.extension Registrare un’estensione di Twig
twig.loader Registrare un servizio personalizzato che carica template Twig
validator.constraint_validator Creare un vincolo di validazione personalizzato
validator.initializer Registrare un servizio che inizializzi gli oggetti prima della validazione

assetic.asset

Scopo: Registrare una risorsa nel gestore di risorse corrente

assetic.factory_worker

Scopo: Aggiungere un factory worker

Un Factory worker è una classe che implementa Assetic\Factory\Worker\WorkerInterface. Il suo metodo process($asset) viene richiamato per ogni risorsa, dopo la creazione. Si può modificare una risorsa o anche restituirne una nuova.

Per poter aggiungere un nuovo worker, creare una classe:

use Assetic\Asset\AssetInterface;
use Assetic\Factory\Worker\WorkerInterface;

class MyWorker implements WorkerInterface
{
    public function process(AssetInterface $asset)
    {
        // ... modificare $asset o restituirne uno nuovo
    }

}

Quindi registrarla come servizio:

  • YAML
    services:
        acme.my_worker:
            class: MyWorker
            tags:
                - { name: assetic.factory_worker }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service id="acme.my_worker" class="MyWorker>
                <tag name="assetic.factory_worker" />
            </service>
        </services>
    </container>
  • PHP
    $container
        ->register('acme.my_worker', 'MyWorker')
        ->addTag('assetic.factory_worker')
    ;
    

assetic.filter

Scopo: Registrare un filtro

AsseticBundle usa questo tag per registrare filtri comuni. Lo si può usare per registrare i propri filtri.

Occorre prima di tutto creare un filtro:

use Assetic\Asset\AssetInterface;
use Assetic\Filter\FilterInterface;

class MyFilter implements FilterInterface
{
    public function filterLoad(AssetInterface $asset)
    {
        $asset->setContent('alert("yo");' . $asset->getContent());
    }

    public function filterDump(AssetInterface $asset)
    {
        // ...
    }
}

Definire quindi un servizio:

  • YAML
    services:
        acme.my_filter:
            class: MyFilter
            tags:
                - { name: assetic.filter, alias: my_filter }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service id="acme.my_filter" class="MyFilter">
                <tag name="assetic.filter" alias="my_filter" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('acme.my_filter', 'MyFilter')
        ->addTag('assetic.filter', array('alias' => 'my_filter'))
    ;
    

Infine applicare il filtro:

{% javascripts
    '@AcmeBaseBundle/Resources/public/js/global.js'
    filter='my_filter'
%}
    <script src="{{ asset_url }}"></script>
{% endjavascripts %}

Si può anche applicare un filtro tramite l’opzione di configurazione assetic.filters.my_filter.apply_to, come spiegato in Applicare i filtri di Assetic a file con specifiche estensioni. Per poterlo fare, si deve definire il servizio per il filtro in un file xml a parte e puntare al percorso di tale file, tramite la chiave di configurazione assetic.filters.my_filter.resource.

assetic.formula_loader

Scopo: Aggiungere un formula loader al gestore di risorse corrente

Un formula loader è una classe che implementa l’interfaccia Assetic\\Factory\Loader\\FormulaLoaderInterface. Tale classe è responsabile del caricamento di risorse di un certo tipo (per esempio, template Twig). Assetic dispone di loader per template PHP e Twig.

Un attributo alias definisce il nome del loader.

assetic.formula_resource

Scopo: Aggiungere una risorsa al gestore di risorse corrente

Una risorsa è qualcosa che possa essere caricato da un formula loader. Per esempio, i template Twig sono risorse.

assetic.templating.php

Scopo: Rimuovere questo servizio se i template PHP sono disabilitati

Il servizio sarà rimosso dal contenitore, se la sezione framework.templating.engines non contiene php.

assetic.templating.twig

Scopo: Rimuovere questo servizio se i template Twig sono disabilitati

Il servizio sarà rimosso dal contenitore, se la sezione framework.templating.engines non contiene twig.

console.command

Nuovo nella versione 2.4: Il supporto per registrare comandi nel contenitore di servizi è stato aggiunto nella versione 2.4.

Scopo: Aggiungere un comand all’applicazione

Per dettagli su come registrare comandi nel contenitore di servizi, leggere the cookbook article.

data_collector

Scopo: creare una classe che raccolga dati personalizzati per il profilatore

Per dettagli su come creare i propri insiemi di dati, leggere la ricetta Come creare un raccoglitore di dati personalizzato.

doctrine.event_listener

Scopo: Aggiungere un ascoltatore di eventi Doctrine

Per dettagli su come creare ascoltatori di eventi, leggere la ricetta Registrare ascoltatori e sottoscrittori di eventi.

doctrine.event_subscriber

Scopo: Aggiungere un sottoscrittore di eventi Doctrine

Per dettagli su come creare sottoscrittori di eventi, leggere la ricetta Registrare ascoltatori e sottoscrittori di eventi.

form.type

Scopo: Creare un tipo di campo personalizzato per i form

Per dettagli su come creare un tipo di campo, leggere la ricetta Creare un tipo di campo personalizzato di un form.

form.type_extension

Scopo: Creare un “form extension” personalizzato

Le estensioni dei form sono un modo per portare un “aggancio” nella creazione di qualsiasi campo di un form. Per esempio, l’aggiunta di un token per il CSRF si fa tramite un’estensione del form (Symfony\Component\Form\Extension\Csrf\Type\FormTypeCsrfExtension).

Un’estensione di form può modificare qualsiasi parte di qualsiasi campo di un form. Per creare un’estensione, creare prima di tutto una classe che implementi l’interfaccia Symfony\Component\Form\FormTypeExtensionInterface. Per semplicità, spesso si estenderà la classe Symfony\Component\Form\AbstractTypeExtension invece che direttamente l’interfaccia:

// src/Acme/MainBundle/Form/Type/MyFormTypeExtension.php
namespace Acme\MainBundle\Form\Type;

use Symfony\Component\Form\AbstractTypeExtension;

class MyFormTypeExtension extends AbstractTypeExtension
{
    // ... inserire i metodi che si vogliono sovrascrivere
    // come buildForm(), buildView(), finishView(), setDefaultOptions()
}

Per far conoscere a Symfony la propria estensione e usarla, usare il tag form.type_extension:

  • YAML
    services:
        main.form.type.my_form_type_extension:
            class: Acme\MainBundle\Form\Type\MyFormTypeExtension
            tags:
                - { name: form.type_extension, alias: field }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service
                id="main.form.type.my_form_type_extension"
                class="Acme\MainBundle\Form\Type\MyFormTypeExtension">
    
                <tag name="form.type_extension" alias="field" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('main.form.type.my_form_type_extension', 'Acme\MainBundle\Form\Type\MyFormTypeExtension')
        ->addTag('form.type_extension', array('alias' => 'field'))
    ;
    

La chiave alias del tag è il tipo di campo a cui questa estensione va applicata. Per esempio, per applicare l’estensione a qualsiasi campo, usare il valore “field”.

form.type_guesser

Scopo: Aggiungere la propria logica per “indovinare” il tipo di form

Questo tag consente di aggiungere la propria logica al processo per indovinare il form. Per impostazione predefinita, il form viene indovinato dagli “indovini”, in base ai metadati di validazione e ai metadati di Doctrine (se si usa Doctrine) o di Propel (se si usa Propel).

Vedi anche

Per sapere come aggiungere i propri indovini, vedere Creare un indovino di tipi.

kernel.cache_clearer

Scopo: Registrare un servizio da richiamare durante la pulizia della cache

La pulizia della cache avviene a ogni chiamata del comando cache:clear. Se un bundle mette dei file in cache, si dovrebbe aggiungere un pulitore personalizzato, per pulirli durante il processo di pulizia della cache.

Per registrare un pulitore personalizzato, occorre innanzitutto creare un servizio:

// src/Acme/MainBundle/Cache/MyClearer.php
namespace Acme\MainBundle\Cache;

use Symfony\Component\HttpKernel\CacheClearer\CacheClearerInterface;

class MyClearer implements CacheClearerInterface
{
    public function clear($cacheDir)
    {
        // pulire i propri file dalla cache
    }

}

Quindi registrare la classe e assegnarle il tag kernel.cache_clearer:

  • YAML
    services:
        mio_pulitore:
            class: Acme\MainBundle\Cache\MioPulitore
            tags:
                - { name: kernel.cache_clearer }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service id="mio_pulitore" class="Acme\MainBundle\Cache\MioPulitore">
                <tag name="kernel.cache_clearer" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('mio_pulitore', 'Acme\MainBundle\Cache\MioPulitore')
        ->addTag('kernel.cache_clearer')
    ;
    

kernel.cache_warmer

Scopo: Registrare un servizio da richiamare durante il processo di preparazione della cache

Ogni volta che si richiama il task cache:warmup o cache:clear, la cache viene preparata (a meno che non si passi --no-warmup a cache:clear). Questo accade anche durante la gestione della richiesta, in mancanza di un precedente comando. Lo scopo è di inizializzare ogni cache necessaria all’applicazione e prevenire un “cache hit”, cioè una generazione dinamica della cache, da parte del primo utente.

Per registrare un preparatore di cache, creare innanzitutto un servizio che implementi l’interfaccia Symfony\Component\HttpKernel\CacheWarmer\CacheWarmerInterface:

// src/Acme/MainBundle/Cache/MyCustomWarmer.php
namespace Acme\MainBundle\Cache;

use Symfony\Component\HttpKernel\CacheWarmer\CacheWarmerInterface;

class MyCustomWarmer implements CacheWarmerInterface
{
    public function warmUp($cacheDir)
    {
        // fare qualcosa per preparare la cache
    }

    public function isOptional()
    {
        return true;
    }
}

Il metodo isOptional deve restituire true se è possibile usare l’applicazione senza richiamare il preparatore di cache. In Symfony, i preparatori facoltativi vengono eseguiti ugualmente (lo si può cambiare, usando l’opzione --no-optional-warmers durante l’esecuzione del comando).

Per registrare un preparatore di cache, usare il tag kernel.cache_warmer:

  • YAML
    services:
        main.warmer.mio_preparatore:
            class: Acme\MainBundle\Cache\MioPreparatore
            tags:
                - { name: kernel.cache_warmer, priority: 0 }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service id="main.warmer.mio_preparatore" class="Acme\MainBundle\Cache\MioPreparatore">
                <tag name="kernel.cache_warmer" priority="0" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('main.warmer.mio_preparatore', 'Acme\MainBundle\Cache\MioPreparatore')
        ->addTag('kernel.cache_warmer', array('priority' => 0))
    ;
    

Nota

Il valore priority è facoltativo ed è predefinito a 0. I prepratori saranno eseguiti con un ordine basato sulla loro priorità.

Preparatori di cache del nucleo

Nome della classe del preparatore Priorità
Symfony\Bundle\FrameworkBundle\CacheWarmer\TemplatePathsCacheWarmer 20
Symfony\Bundle\FrameworkBundle\CacheWarmer\RouterCacheWarmer 0
Symfony\Bundle\TwigBundle\CacheWarmer\TemplateCacheCacheWarmer 0

kernel.event_listener

Scopo: Ascoltare vari eventi/agganci in Symfony

Questo tag consente di agganciare le proprie classi al processo di Symfony, in vari punti.

Per un esempio completo di questo ascoltatore, leggere la ricetta Creare un ascoltatore di eventi.

Per altri esempi pratici di un ascoltatore del nucleo, vedere la ricetta Registrare un nuovo formato di richiesta e un nuovo tipo mime.

Riferimenti sugli ascoltatori del nucleo

Quando si aggiungono i propri ascoltatori, potrebbe essere utile conoscere gli altri ascoltatori del nucleo di Symfony e le loro priorità.

Nota

Tutti gli ascoltatori qui elencati potrebbero non ascoltare, a seconda di ambiente, impostazioni e bundle. Inoltre, bundle di terze parti potrebbero aggiungere altri ascoltatori, non elencati qui.

kernel.request

Nome della classe dell’ascoltatore Priorità
Symfony\Component\HttpKernel\EventListener\ProfilerListener 1024
Symfony\Bundle\FrameworkBundle\EventListener\TestSessionListener 192
Symfony\Bundle\FrameworkBundle\EventListener\SessionListener 128
Symfony\Component\HttpKernel\EventListener\RouterListener 32
Symfony\Component\HttpKernel\EventListener\LocaleListener 16
Symfony\Component\Security\Http\Firewall 8

kernel.controller

Nome della classe dell’ascoltatore Priorità
Symfony\Bundle\FrameworkBundle\DataCollector\RequestDataCollector 0

kernel.response

Nome della classe dell’ascoltatore Priorità
Symfony\Component\HttpKernel\EventListener\EsiListener 0
Symfony\Component\HttpKernel\EventListener\ResponseListener 0
Symfony\Bundle\SecurityBundle\EventListener\ResponseListener 0
Symfony\Component\HttpKernel\EventListener\ProfilerListener -100
Symfony\Bundle\FrameworkBundle\EventListener\TestSessionListener -128
Symfony\Bundle\WebProfilerBundle\EventListener\WebDebugToolbarListener -128
Symfony\Component\HttpKernel\EventListener\StreamedResponseListener -1024

kernel.exception

Nome della classe dell’ascoltatore Priorità
Symfony\Component\HttpKernel\EventListener\ProfilerListener 0
Symfony\Component\HttpKernel\EventListener\ExceptionListener -128

kernel.terminate

Nome della classe dell’ascoltatore Priorità
EmailSenderListener 0

kernel.event_subscriber

Scopo: Sottoscrivere un insieme di vari eventi/agganci in Symfony

Per abilitare un sottoscrittore personalizzato, aggiungerlo come normale servizio in una delle configurazioni e assegnarli il tag kernel.event_subscriber:

  • YAML
    services:
        kernel.subscriber.nome_sottoscrittore:
            class: Nome\Pienamente\QUalificato\Classe\Subscriber
            tags:
                - { name: kernel.event_subscriber }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service
                id="kernel.subscriber.nome_sottoscrittore"
                class="Nome\Pienamente\QUalificato\Classe\Subscriber">
    
                <tag name="kernel.event_subscriber" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('kernel.subscriber.nome_sottoscrittore', 'Nome\Pienamente\QUalificato\Classe\Subscriber')
        ->addTag('kernel.event_subscriber')
    ;
    

Nota

Il servizio deve implementare l’inferfaccia SymfonyComponentEventDispatcherEventSubscriberInterface.

Nota

Se il servizio è creato da un factory, si DEVE impostare correttamente il parametro class del tag, per poterlo far funzionare correttamente.

kernel.fragment_renderer

Scopo: Aggiunta di una nuova strategia di resa del contenuto HTTP.

Per aggiungere una nuova strategia di resa, in aggiunta a quelle predefinite come EsiFragmentRenderer, creare una classe che implementi Symfony\Component\HttpKernel\Fragment\FragmentRendererInterface, registrarla come servizio, assegnando il tag kernel.fragment_renderer.

monolog.logger

Scopo: Usare un canale di log personalizzato con Monolog

Monolog consente di condividere i suoi gestori tra vari canali di log. Il servizio logger usa il canale app, ma si può cambiare il canale quando si inietta il logger in un servizio.

  • YAML
    services:
        mio_servizio:
            class: Nome\Pienamente\QUalificato\Classe\Loader
            arguments: ["@logger"]
            tags:
                - { name: monolog.logger, channel: acme }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service id="mio_servizio" class="Nome\Pienamente\QUalificato\Classe\Loader">
                <argument type="service" id="logger" />
                <tag name="monolog.logger" channel="acme" />
            </service>
        </services>
    </container>
    
  • PHP
    $definition = new Definition('Nome\Pienamente\QUalificato\Classe\Loader', array(new Reference('logger'));
    $definition->addTag('monolog.logger', array('channel' => 'acme'));
    $container->register('mio_servizio', $definition);;
    

Suggerimento

Se si usa MonologBundle 2.4 o successivi, si possono configurare canali personalizzati nella configurazione e recuperare il corrispondente servizio logger direttamente dal contenitore di servizi (vedere Configurare canali aggiuntivi senza tag dei servizi).

monolog.processor

Scopo: Aggiungere un processore personalizzato per i log

Monolog consente di aggiungere processori nel logger o nei gestori, per aggiungere dati extra nelle registrazioni. Un processore riceve la registrazione come parametro e deve restituirlo dopo aver aggiunto degli extra nell’attributo extra della registrazione.

Vediamo come usare IntrospectionProcessor per aggiungere nome del file, riga, classe e metodo in cui il logger è stato fatto partire.

Si può aggiungere un processore globalmente:

  • YAML
    services:
        mio_servizio:
            class: Monolog\Processor\IntrospectionProcessor
            tags:
                - { name: monolog.processor }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service id="mio_servizio" class="Monolog\Processor\IntrospectionProcessor">
                <tag name="monolog.processor" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('mio_servizio', 'Monolog\Processor\IntrospectionProcessor')
        ->addTag('monolog.processor')
    ;
    

Suggerimento

Se il servizio non è richiamabile (usando __invoke), si può aggiungere l’attributo method nel tag, per usare un metodo specifico.

Si può anche aggiungere un processore per un gestore specifico, usando l’attributo handler:

  • YAML
    services:
        mio_servizio:
            class: Monolog\Processor\IntrospectionProcessor
            tags:
                - { name: monolog.processor, handler: firephp }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service id="mio_servizio" class="Monolog\Processor\IntrospectionProcessor">
                <tag name="monolog.processor" handler="firephp" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('mio_servizio', 'Monolog\Processor\IntrospectionProcessor')
        ->addTag('monolog.processor', array('handler' => 'firephp'))
    ;
    

Si può anche aggiungere un processore per uno specifico canale di log, usando l’attributo channel. Il seguente registrerà il processore solo per il canale di log security, usato dal componente Security:

  • YAML
    services:
        mio_servizio:
            class: Monolog\Processor\IntrospectionProcessor
            tags:
                - { name: monolog.processor, channel: security }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service id="mio_servizio" class="Monolog\Processor\IntrospectionProcessor">
                <tag name="monolog.processor" channel="security" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('mio_servizio', 'Monolog\Processor\IntrospectionProcessor')
        ->addTag('monolog.processor', array('channel' => 'security'))
    ;
    

Nota

Non si può usare sia l’attributo handler che channel per lo stesso tag, perché i gestori sono condivisi tra tutti i canali.

routing.loader

Scopo: Registrare un servizio che carichi delle rotte

Per abilitare un caricatore di rotte personalizzato, aggiungerlo come servizio in una configurazione e assegnargli il tag routing.loader:

  • YAML
    services:
        routing.loader.nome_caricatore:
            class: Nome\Pienamente\QUalificato\Classe\Caricatore
            tags:
                - { name: routing.loader }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service
                id="routing.loader.nome_caricatore"
                class="Nome\Pienamente\QUalificato\Classe\Caricatore">
    
                <tag name="routing.loader" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('routing.loader.nome_caricatore', 'Nome\Pienamente\QUalificato\Classe\Caricatore')
        ->addTag('routing.loader')
    ;
    

Per maggiori informazioni, vedere Creare un caricatore di rotte personalizzato.

security.remember_me_aware

Scopo: Consetire il “ricordami” nell’autenticazione

Questo tag è usato internamente per consentire il “ricordami” nell’autenticazione. Se si ha un metodo di autenticazione personalizzato, in cui l’utente può essere ricordato, occorre usare questo tag.

Se il factory di autenticazione personalizzato estende Symfony\Bundle\SecurityBundle\DependencyInjection\Security\Factory\AbstractFactory e l’ascoltatore di autenticazione personalizzato estende Symfony\Component\Security\Http\Firewall\AbstractAuthenticationListener, allora l’ascoltatore avrà automaticamente questo tag applicato e funzionerà tutto in modo automatico.

security.voter

Scopo: Aggiungere un votante personalizzato alla logica di autorizzazione di Symfony

Quando si riciama isGranted nel contesto di sicurezza di Symfony, viene usato dietro le quinte un sistema di “votanti”, per determinare se l’utente possa accedere. Il tag security.voter consente di aggiungere un votante personalizzato a tale sistema.

Per maggiori informazioni, leggere la ricetta Implementare dei votanti per una lista nera di indirizzi IP.

serializer.encoder

Scopo: Registrare un nuovo codificatore nel servizio serializer

La classe con il tag deve implementare Symfony\Component\Serializer\Encoder\EncoderInterface e Symfony\Component\Serializer\Encoder\DecoderInterface.

Per maggiori dettagli, vedere Come usare il Serializer.

serializer.normalizer

Scopo: Registrare un nuovo normalizzatore nel servizio serializer

La classe con il tag deve implementare Symfony\Component\Serializer\Normalizer\NormalizerInterface e Symfony\Component\Serializer\Normalizer\DenormalizerInterface.

Per maggiori dettagli, vedere Come usare il Serializer.

swiftmailer.plugin

Scopo: Registrare un plugin di SwiftMailer

Se si usa (o si vuole creare) un plugin di SwiftMailer, lo si può registrare con SwiftMailer creando un servizio per il plugin e assegnadogli il tag swiftmailer.default.plugin (che non ha opzioni).

Nota

In questo tag, default è il nome del mailer. Se si hanno più mailer configurati o se per qualche motivo è stato cambiato il nome del mailer predefinito, anche in questo tag il nome va cambiato di conseguenza.

Un plugin di SwiftMailer deve implementare l’interfaccia Swift_Events_EventListener. Per maggiori informazioni sui plugin, vedere la documentazione dei plugin di SwiftMailer.

Molti plugin di SwiftMailer sono nel nucleo di Symfony e possono essere attivati tramite varie configurazioni. Per dettagli, vedere Configurazione di SwiftmailerBundle (“swiftmailer”).

templating.helper

Scopo: Rendere dei servizi disponibili nei template PHP

Per abilitare un aiutante personalizzato per i template, aggiungerlo come normale servizio in una configurazione, assegnarli il tag templating.helper e definire un attributo alias (l’aiutante sarà accessibile tramite tale alias nei template):

  • YAML
    services:
        templating.helper.mio_aiutante:
            class: Nome\Pienamente\QUalificato\Classe\Aiutante
            tags:
                - { name: templating.helper, alias: nome_alias }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service
                id="templating.helper.mio_aiutante"
                class="Nome\Pienamente\QUalificato\Classe\Aiutante">
    
                <tag name="templating.helper" alias="_alias" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('templating.helper.mio_aiutante', 'Nome\Pienamente\QUalificato\Classe\Aiutante')
        ->addTag('templating.helper', array('alias' => 'nome_alias'))
    ;
    

translation.loader

Scopo: Registrare un servizio personalizzato che carichi delle traduzioni

Per impostazione predefinita, le traduzioni sono caricate dal filesystem in vari formati (YAML, XLIFF, PHP, ecc).

Vedi anche

Si può vedere come caricare formati personalizzati nella sezione relativa ai componenti.

Registrare il caricatore come servizio e assegnargli il tag translation.loader:

  • YAML
    services:
        main.translation.mio_caricatore:
            class: Acme\MainBundle\Translation\MioCaricatore
            tags:
                - { name: translation.loader, alias: bin }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service
                id="main.translation.mio_caricatore"
                class="Acme\MainBundle\Translation\MioCaricatore">
    
                <tag name="translation.loader" alias="bin" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('main.translation.mio_caricatore', 'Acme\MainBundle\Translation\MioCaricatore')
        ->addTag('translation.loader', array('alias' => 'bin'))
    ;
    

L’opzione alias è obbligatoria e molto importante: definisce il “suffisso” del file che sarà usato per i file risorsa che usano questo caricatore. Per esempio, si supponga di avere un formato personalizzato bin, da caricare. Se si ha un file bin che contiene traduzioni in francese per il dominio messages, si potrebbe avere un file app/Resources/translations/messages.fr.bin.

Quando Symfony prova a caricare il file bin, passa il percorso del caricatore personalizzato nel parametro $resource. Si può quindi implementare la logica desiderata su tale file, in modo da caricare le proprie traduzioni.

Se si caricano traduzioni da una base dati, occorrerà comunque un file risorsa, ma potrebbe essere vuoto o contenere poche informazioni sul caricamento di tali risorse dalla base dati. Il file è la chiave per far scattare il metodo load del caricatore personalizzato.

translation.extractor

Scopo: Registrare un servizio personalizzato che estragga messaggi da un file

Quando si esegue il comando translation:update, esso usa degli estrattori per estrarre messaggi di traduzione da un file. Per impostazione predefinita, Symfony ha un Symfony\Bridge\Twig\Translation\TwigExtractor e un Symfony\Bundle\FrameworkBundle\Translation\PhpExtractor, che aiutano a trovare ed estrarre chiavi di traduzione da template Twig e file PHP.

Si può creare un estrattore, creando una classe che implementi Symfony\Component\Translation\Extractor\ExtractorInterface e assegnado al servizio il tag translation.extractor. Il tag ha un’opzione obbligatoria: alias, che definisce il nome dell’estrattore:

// src/Acme/DemoBundle/Translation/PippoExtractor.php
namespace Acme\DemoBundle\Translation;

use Symfony\Component\Translation\Extractor\ExtractorInterface;
use Symfony\Component\Translation\MessageCatalogue;

class PippoExtractor implements ExtractorInterface
{
    protected $prefix;

    /**
     * Estrae messaggi di traduzione da una cartella di template al catalogo.
     */
    public function extract($directory, MessageCatalogue $catalogue)
    {
        // ...
    }

    /**
     * Imposta il prefisso da usare per i nuovi messaggi trovati.
     */
    public function setPrefix($prefix)
    {
        $this->prefix = $prefix;
    }
}
  • YAML
    services:
        acme_demo.translation.extractor.foo:
            class: Acme\DemoBundle\Translation\PippoExtractor
            tags:
                - { name: translation.extractor, alias: foo }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service
                id="acme_demo.translation.extractor.foo"
                class="Acme\DemoBundle\Translation\PippoExtractor">
    
                <tag name="translation.extractor" alias="foo" />
            </service>
        </services>
    </container>
    
  • PHP
    $container->register(
        'acme_demo.translation.extractor.pippo',
        'Acme\DemoBundle\Translation\PippoExtractor'
    )
        ->addTag('translation.extractor', array('alias' => 'pippo'));
    

translation.dumper

Scopo: Registrare un servizio personalizzato che esporti messaggi in un file

Dopo che un Extractor ha estratto tutti i messaggi dai template, vengono eseguiti gli esportatori, per esportare i messaggi in un file di traduzione in uno specifico formato.

Symfony dispone di diversi esportatori:

  • Symfony\Component\Translation\Dumper\CsvFileDumper
  • Symfony\Component\Translation\Dumper\IcuResFileDumper
  • Symfony\Component\Translation\Dumper\IniFileDumper
  • Symfony\Component\Translation\Dumper\MoFileDumper
  • Symfony\Component\Translation\Dumper\PoFileDumper
  • Symfony\Component\Translation\Dumper\QtFileDumper
  • Symfony\Component\Translation\Dumper\XliffFileDumper
  • Symfony\Component\Translation\Dumper\YamlFileDumper

Si può creare un estrattore, estendendo Symfony\Component\Translation\Dumper\FileDumper o implementando Symfony\Component\Translation\Dumper\DumperInterface e assegnado al servizio il tag translation.dumper. Il tag ha un’unica opzione: alias È il nome usato per determinare quale esportatore va usato.

  • YAML
    services:
        acme_demo.translation.dumper.json:
            class: Acme\DemoBundle\Translation\JsonFileDumper
            tags:
                - { name: translation.dumper, alias: json }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service
                id="acme_demo.translation.dumper.json"
                class="Acme\DemoBundle\Translation\JsonFileDumper">
    
                <tag name="translation.dumper" alias="json" />
            </service>
        </services>
    </container>
    
  • PHP
    $container->register(
        'acme_demo.translation.dumper.json',
        'Acme\DemoBundle\Translation\JsonFileDumper'
    )
        ->addTag('translation.dumper', array('alias' => 'json'));
    

Vedi anche

Si veda come esportare in formati personalizzati nella sezione dei componenti.

twig.extension

Scopo: Registrare un’estensione personalizzata di Twig

Per abilitare un’estensione di Twig, aggiungere un normale servizio in una configurazione e assegnargli il tag twig.extension:

  • YAML
    services:
        twig.extension.nome_estensione:
            class: Nome\Pienamente\QUalificato\Classe\Extension
            tags:
                - { name: twig.extension }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service
                id="twig.extension.nome_estensione"
                class="Nome\Pienamente\QUalificato\Classe\Extension">
    
                <tag name="twig.extension" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('twig.extension.nome_estensione', 'Nome\Pienamente\QUalificato\Classe\Extension')
        ->addTag('twig.extension')
    ;
    

Per sapere come creare la classe estensione di Twig, vedere la documentazione di Twig sull’argomento oppure leggere la ricetta Scrivere un’estensione Twig personalizzata

Prima di scrivere la propria estensione, dare un’occhiata al repository ufficiale delle estensioni di Twig, che contiene molte estensioni utili. Per esempio, Intl e il suo filtro localizeddate, che formatta una data in base al locale dell’utente. Anche aueste estensioni ufficiali di Twig devono essere aggiunte come normali servizi:

  • YAML
    services:
        twig.extension.intl:
            class: Twig_Extensions_Extension_Intl
            tags:
                - { name: twig.extension }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service id="twig.extension.intl" class="Twig_Extensions_Extension_Intl">
                <tag name="twig.extension" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('twig.extension.intl', 'Twig_Extensions_Extension_Intl')
        ->addTag('twig.extension')
    ;
    

twig.loader

Scopo: Registrare un servizio personalizzato che carica template Twig

Per impostazione predefinita, Symfony usa solo la classe Twig Loader. Symfony\Bundle\TwigBundle\Loader\FilesystemLoader. Se si ha l’esigenza di caricare template Twig da un’altra risorsa, si può creare un servizio per il nuovo caricatore e assegnarli il tag twig.loader:

  • YAML
    services:
        acme.demo_bundle.loader.caricatore_twig:
            class: Acme\DemoBundle\Loader\CaricatoreTwig
            tags:
                - { name: twig.loader }
    
  • XML
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
    
        <services>
            <service
                id="acme.demo_bundle.loader.caricatore_twig"
                class="Acme\DemoBundle\Loader\CaricatoreTwig">
    
                <tag name="twig.loader" />
            </service>
        </services>
    </container>
    
  • PHP
    $container
        ->register('acme.demo_bundle.loader.caricatore_twig', 'Acme\DemoBundle\Loader\CaricatoreTwig')
        ->addTag('twig.loader')
    ;
    

validator.constraint_validator

Scopo: Creare un vincolo di validazione personalizzato

Questo tag consente di creare e registrare i propri vincoli di validazione. Per maggiori informazioni, leggere la ricetta Creare vincoli di validazione personalizzati.

validator.initializer

Scopo: Registrare un servizio che inizializzi gli oggetti prima della validazione

Questo tag fornisce un pezzo di funzionalità non comune, che consente di eseguire alcune azioni su un oggetto prima che venga validato. Per esempio, è usato da Doctrine per cercare tutti i dati di un oggetto caricati in modo pigro, prima che venga validato. Senza questo, alcuni dati su un entità Doctrine apparirebbero come mancanti durante la validazione, anche se non lo fossero realmente.

Se si deve usare questo tag, fare una nuova classe che implementi l’interfaccia Symfony\Component\Validator\ObjectInitializerInterface. Quindi, assegnare il tag validator.initializer (che non ha opzioni).

Per un esempio, vedere la classe EntityInitializer dentro Doctrine Bridge.