Las etiquetas para la inyección de dependencia son pequeñas cadenas que se pueden aplicar a la «bandera» de un servicio para poder usarla de alguna manera especial. Por ejemplo, si tienes un servicio que quieres registrar como escucha de uno de los principales eventos de Symfony, lo puedes marcar con la etiqueta kernel.event_listener.
Puedes aprender un poco más sobre las «etiquetas» leyendo la sección «Etiquetas» del capítulo Contenedor de Servicio.
A continuación mostramos información sobre todas las etiquetas disponibles en Symfony2. También puede haber etiquetas usadas en otros paquetes que no aparecen aquí. Por ejemplo, AsseticBundle tiene muchas etiquetas no mencionadas aquí.
| Tag Name | Usage |
| data_collector | Create a class that collects custom data for the profiler |
| form.type | Create a custom form field type |
| form.type_extension | Create a custom “form extension” |
| form.type_guesser | Add your own logic for “form type guessing” |
| kernel.cache_warmer | Register your service to be called during the cache warming process |
| kernel.event_listener | Listen to different events/hooks in Symfony |
| kernel.event_subscriber | To subscribe to a set of different events/hooks in Symfony |
| kernel.fragment_renderer | Add new HTTP content rendering strategies |
| monolog.logger | Logging with a custom logging channel |
| monolog.processor | Add a custom processor for logging |
| routing.loader | Register a custom service that loads routes |
| security.voter | Add a custom voter to Symfony’s authorization logic |
| security.remember_me_aware | To allow remember me authentication |
| security.listener.factory | Necessary when creating a custom authentication system |
| serializer.encoder | Register a new encoder in the serializer service |
| serializer.normalizer | Register a new normalizer in the serializer service |
| swiftmailer.plugin | Register a custom SwiftMailer Plugin |
| templating.helper | Make your service available in PHP templates |
| translation.loader | Register a custom service that loads translations |
| twig.extension | Register a custom Twig Extension |
| twig.loader | Register a custom service that loads Twig templates |
| validator.constraint_validator | Create your own custom validation constraint |
| validator.initializer | Register a service that initializes objects before validation |
Propósito: Crear una clase que recopile datos personalizados para el generador de perfiles
Para información detallada sobre cómo crear tu propio recolector de datos personalizado, lee el artículo en el recetario: Cómo crear un colector de datos personalizado.
Propósito: Crear un tipo de campo de formulario personalizado
Para obtener más información sobre cómo crear tu propio tipo de formulario personalizado, lee el artículo en el recetario: Cómo crear un tipo de campo personalizado para formulario.
Propósito: Crear una «extensión personalizada de Form»
Las extensiones de tipo Form son una manera para «enganchar» la creación de cualquier campo en tu formulario. Por ejemplo, la adición del fragmento CSRF se hace a través de una extensión del tipo Form (la clase Symfony\Component\Form\Extension\Csrf\Type\FormTypeCsrfExtension).
Una extensión del tipo Form puede modificar cualquier parte de cualquier campo en tu formulario. Para crear una extensión del tipo Form, primero debes crear una clase que implemente la interfaz Symfony\Component\Form\FormTypeExtensionInterface. Por simplicidad, a menudo extenderás una clase Symfony\Component\Form\AbstractTypeExtension en lugar de la interfaz directamente:
// src/Acme/MainBundle/Form/Type/MyFormTypeExtension.php
namespace Acme\MainBundle\Form\Type;
use Symfony\Component\Form\AbstractTypeExtension;
class MyFormTypeExtension extends AbstractTypeExtension
{
// ... rellena cualquier método que quieras redefinir
// como buildForm(), buildView(), finishView(), setDefaultOptions()
}
Para dar a conocer tu extensión del tipo Form a Symfony y usarla, ponle la etiqueta form.type_extension:
services:
main.form.type.my_form_type_extension:
class: Acme\MainBundle\Form\Type\MyFormTypeExtension
tags:
- { name: form.type_extension, alias: field }
<service id="main.form.type.my_form_type_extension" class="Acme\MainBundle\Form\Type\MyFormTypeExtension">
<tag name="form.type_extension" alias="field" />
</service>
$container
->register('main.form.type.my_form_type_extension', 'Acme\MainBundle\Form\Type\MyFormTypeExtension')
->addTag('form.type_extension', array('alias' => 'field'))
;
La clave alias de la etiqueta es el tipo de campo al que esta extensión se debe aplicar. Por ejemplo, para aplicar la extensión a cualquier «campo», utiliza el valor 'field'.
Propósito: Añade tu propia lógica para «deducir el tipo del formulario»
Esta etiqueta te permite agregar tu propia lógica al proceso de Deducción del tipo del formulario. De manera predeterminada, la deducción del tipo del formulario se hace por medio de «inferencias» basadas en los metadatos de validación y de Doctrine (si estás usando Doctrine).
Para añadir tu propio adivino del tipo de formulario, crea una clase que implemente la interfaz Symfony\Component\Form\FormTypeGuesserInterface. A continuación, marca la definición de este servicio con form.type_guesser (esta no tiene opciones).
Para ver un ejemplo de cómo podría ser esta clase, consulta la clase ValidatorTypeGuesser en el componente Form.
Propósito: Registra tu servicio para que sea llamado durante el proceso de precalentamiento para el almacenamiento en caché.
El precalentamiento de la caché se produce cuando ejecutas la tarea cache:warmup o cache:clear (a menos que pases -no-warmp a cache:clear). El propósito es iniciar cualquier caché que necesitará la aplicación y evitar que el primer usuario de algún «uso de caché» importante genera dinámicamente la memoria caché.
Para registrar tu propio precalentamiento de caché, en primer lugar crea un servicio que implemente la interfaz 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)
{
// hacer algún tipo de operaciones para "calentar" tu memoria caché
}
public function isOptional()
{
return true;
}
}
El método isOptional debe devolver true si es posible utilizar la aplicación sin necesidad de llamar al precalentamiento de caché. En Symfony 2.0, los precalentadores opcionales de cualquier modo siempre se ejecutan, por lo tanto esta función no tiene ningún efecto real.
Para registrar tu precalentador en Symfony, ponle la etiqueta kernel.cache_warmer:
services:
main.warmer.my_custom_warmer:
class: Acme\MainBundle\Cache\MyCustomWarmer
tags:
- { name: kernel.cache_warmer, priority: 0 }
<service id="main.warmer.my_custom_warmer" class="Acme\MainBundle\Cache\MyCustomWarmer">
<tag name="kernel.cache_warmer" priority="0" />
</service>
$container
->register('main.warmer.my_custom_warmer', 'Acme\MainBundle\Cache\MyCustomWarmer')
->addTag('kernel.cache_warmer', array('priority' => 0))
;
El valor priority es opcional y por omisión es 0. Este valor puede estar en el rango de -255 a 255, y los precalentadores se ejecutan en ese orden de prioridad.
Propósito: Para escuchar los diferentes eventos o ganchos en Symfony
Esta etiqueta te permite conectar tus propias clases en diferentes puntos del proceso de Symfony.
Para ver un ejemplo completo de este escucha, ve el artículo Cómo crear un escucha de evento del recetario.
Para otro ejemplo práctico de un escucha del núcleo consulta en el recetario el artículo: Cómo registrar un nuevo formato de petición y tipo MIME.
Al agregar tus propios escuchas, puede ser útil saber sobre los otros escuchas del núcleo de Symfony y sus prioridades.
Nota
Todos los escuchas enumerados aquí posiblemente no figuren dependiendo de tu entorno, configuración y paquetes. Además, los paquetes de terceros traerán escucha adicionales que no figuran en esta lista.
| Nombre de la clase escucha | Prioridad |
| 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 |
| Nombre de la clase escucha | Prioridad |
| Symfony\Bundle\FrameworkBundle\DataCollector\RequestDataCollector | 0 |
| Nombre de la clase escucha | Prioridad |
| 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 |
| Nombre de la clase escucha | Prioridad |
| Symfony\Component\HttpKernel\EventListener\ProfilerListener | 0 |
| Symfony\Component\HttpKernel\EventListener\ExceptionListener | -128 |
| Nombre de la clase escucha | Prioridad |
| Symfony\Bundle\SwiftmailerBundle\EventListener\EmailSenderListener | 0 |
Propósito: Para suscribirse a un conjunto de diferentes eventos o ganchos en Symfony.
Nuevo en la versión 2.1: La habilidad para añadir suscriptores a eventos del núcleo se agregó en la versión 2.1.
Para habilitar un suscriptor personalizado, agrégalo como un servicio regular en una de tus configuraciones, y etiquétalo con kernel.event_subscriber:
services:
kernel.subscriber.your_subscriber_name:
class: Nombre\De\Clase\Del\Suscriptor\Completamente\Cualificado
tags:
- { name: kernel.event_subscriber }
<service id="kernel.subscriber.your_subscriber_name" class="Nombre\De\Clase\Del\Suscriptor\Completamente\Cualificado">
<tag name="kernel.event_subscriber" />
</service>
$container
->register('kernel.subscriber.your_subscriber_name', 'Nombre\De\Clase\Del\Suscriptor\Completamente\Cualificado')
->addTag('kernel.event_subscriber')
;
Nota
Tu servicio debe implementar la SymfonyComponentEventDispatcherEventSubscriberInterface.
Nota
Si tu servicio es creado por una factoría, DEBES establecer correctamente el parámetro class para que esta etiqueta trabaje correctamente.
Propósito: Add a new HTTP content rendering strategy.
To add a new rendering strategy - in addition to the core strategies like EsiFragmentRenderer - create a class that implements Symfony\Component\HttpKernel\Fragment\FragmentRendererInterface, register it as a service, then tag it with kernel.fragment_renderer.
Propósito: Para utilizar un canal personalizado para el registro cronológico de eventos con Monolog.
Monolog te permite compartir sus controladores entre varios canales del registro cronológico de eventos. El servicio de registro cronológico utiliza el canal app pero puedes cambiar el canal cuando inyectes el registro cronológico en un servicio.
services:
my_service:
class: Nombre\De\Clase\Del\Cargador\Completamente\Cualificado
arguments: ["@logger"]
tags:
- { name: monolog.logger, channel: acme }
<service id="my_service" class="Nombre\De\Clase\Del\Cargador\Completamente\Cualificado">
<argument type="service" id="logger" />
<tag name="monolog.logger" channel="acme" />
</service>
$definition = new Definition('Nombre\De\Clase\Del\Cargador\Completamente\Cualificado', array(new Reference('logger'));
$definition->addTag('monolog.logger', array('channel' => 'acme'));
$container->register('my_service', $definition);
Nota
Esto sólo funciona cuando el servicio del registro cronológico es un argumento del constructor, no cuando se inyecta a través de un definidor.
Propósito: Añadir un procesador personalizado al registro cronológico.
Monolog te permite agregar procesadores al registro cronológico o a los controladores para añadir datos adicionales en los registros. Un procesador recibe el registro como argumento y lo tiene que devolver después de añadir alguna información adicional en el atributo extra del registro.
Vamos a ver cómo puedes utilizar el IntrospectionProcessor integrado para agregar el archivo, la línea, la clase y el método en que se activó el registro cronológico.
Puedes agregar un procesador globalmente:
services:
my_service:
class: Monolog\Processor\IntrospectionProcessor
tags:
- { name: monolog.processor }
<service id="my_service" class="Monolog\Processor\IntrospectionProcessor">
<tag name="monolog.processor" />
</service>
$definition = new Definition('Monolog\Processor\IntrospectionProcessor');
$definition->addTag('monolog.processor');
$container->register('my_service', $definition);
Truco
Si el servicio no es ejecutable (con __invoke) puedes agregar el atributo method en la etiqueta para utilizar un método específico.
También puedes agregar un procesador para un controlador específico utilizando el atributo handler:
services:
my_service:
class: Monolog\Processor\IntrospectionProcessor
tags:
- { name: monolog.processor, handler: firephp }
<service id="my_service" class="Monolog\Processor\IntrospectionProcessor">
<tag name="monolog.processor" handler="firephp" />
</service>
$definition = new Definition('Monolog\Processor\IntrospectionProcessor');
$definition->addTag('monolog.processor', array('handler' => 'firephp');
$container->register('my_service', $definition);
También puedes agregar un procesador para un canal del registro cronológico específico usando el atributo channel. Esto registrará el procesador únicamente para el canal de registro cronológico de security utilizado en el componente de seguridad:
services:
my_service:
class: Monolog\Processor\IntrospectionProcessor
tags:
- { name: monolog.processor, channel: security }
<service id="my_service" class="Monolog\Processor\IntrospectionProcessor">
<tag name="monolog.processor" channel="security" />
</service>
$definition = new Definition('Monolog\Processor\IntrospectionProcessor');
$definition->addTag('monolog.processor', array('channel' => 'security');
$container->register('my_service', $definition);
Nota
No puedes utilizar ambos atributos handler y channel para la misma etiqueta debido a que los controladores se comparten entre todos los canales.
Propósito: Registrar un servicio personalizado que carga rutas.
Para habilitar un cargador de enrutado personalizado, añádelo como un servicio regular en tu configuración, y etiquétalo con routing.loader:
services:
routing.loader.your_loader_name:
class: Nombre\De\Clase\Completamente\Cualificado
tags:
- { name: routing.loader }
<service id="routing.loader.your_loader_name" class="Nombre\De\Clase\Completamente\Cualificado">
<tag name="routing.loader" />
</service>
$container
->register('routing.loader.your_loader_name', 'Nombre\De\Clase\Del\Cargador\Completamente\Cualificado')
->addTag('routing.loader')
;
For more information, see How to create a custom Route Loader.
Propósito: Necesaria cuando creas un sistema de autenticación personalizado.
Esta etiqueta se utiliza al crear tu propio sistema de autenticación personalizado. Para más información, consulta Cómo crear un proveedor de autenticación personalizado.
Propósito: Para permitir la autenticación «recuérdame».
Esta etiqueta se utiliza internamente para permitir que trabaje la autenticación por recordatorio. Si tienes un método de autenticación personalizado en que el usuario se pueda autenticar por medio de recordatorio, entonces posiblemente tengas que utilizar esta etiqueta.
Si tu factoría de autenticación personalizada extiende la clase Symfony\Bundle\SecurityBundle\DependencyInjection\Security\Factory\AbstractFactory y tu escucha de autenticación personalizado extiende la clase Symfony\Component\Security\Http\Firewall\AbstractAuthenticationListener, entonces el escucha de autenticación personalizado ya está etiquetado y funcionará automáticamente.
Propósito: Agregar un votante personalizado a la lógica de autorización de Symfony.
Cuando llamas a isGranted en el contexto de seguridad de Symfony, detrás del escenario se usa un sistema de «votantes» para determinar si el usuario debe tener acceso. La etiqueta security.voter te permite agregar tu propio votante personalizado al sistema.
Para obtener más información, lee el artículo del recetario: Cómo implementar tu propio votante para agregar direcciones IP a la lista negra.
Propósito: Register a new encoder in the serializer service
The class that’s tagged should implement the Symfony\Component\Serializer\Encoder\EncoderInterface and Symfony\Component\Serializer\Encoder\DecoderInterface.
For more details, see How to use the Serializer.
Propósito: Register a new normalizer in the Serializer service
The class that’s tagged should implement the Symfony\Component\Serializer\Normalizer\NormalizerInterface and Symfony\Component\Serializer\Normalizer\DenormalizerInterface.
For more details, see How to use the Serializer.
Propósito: Registrar un complemento personalizado a SwiftMailer.
Si estás usando un complemento personalizado para SwiftMailer (o deseas crear uno), lo puedes registrar en SwiftMailer creando un servicio para tu complemento y etiquétalo como swiftmailer.plugin (que no tiene opciones).
Un complemento de SwiftMailer debe implementar la interfaz Swift_Events_EventListener. Para más información sobre los complementos, consulta la sección Complemento para SwiftMailer de su documentación.
Varios complementos de SwiftMailer son fundamentales para Symfony y los puedes activar a través de diversa configuración. Para obtener más información, consulta Configurando el SwiftmailerBundle (“swiftmailer”).
Propósito: Poner tu servicio a disposición de las plantillas PHP
Para habilitar un ayudante de plantilla personalizado, añádelo como un servicio regular en tu configuración, etiquétalo con templating.helper y define un atributo alias (el ayudante será accesible a través de este alias en las plantillas):
services:
templating.helper.your_helper_name:
class: Nombre\De\Clase\Ayudante\Completamente\Cualificado
tags:
- { name: templating.helper, alias: alias_name }
<service id="templating.helper.your_helper_name" class="Nombre\De\Clase\Ayudante\Completamente\Cualificado">
<tag name="templating.helper" alias="alias_name" />
</service>
$container
->register('templating.helper.your_helper_name', 'Nombre\De\Clase\Ayudante\Completamente\Cualificado')
->addTag('templating.helper', array('alias' => 'alias_name'))
;
Propósito: Registrar un servicio personalizado que carga traducciones.
De forma predeterminada, las traducciones se cargan desde el sistema de archivos en una variedad de diferentes formatos (YAML, XLIFF, PHP, etc.). Si necesitas cargar traducciones de alguna otra fuente, en primer lugar crea una clase que implemente la interfaz Symfony\Component\Translation\Loader\LoaderInterface:
// src/Acme/MainBundle/Translation/MyCustomLoader.php
namespace Acme\MainBundle\Translation;
use Symfony\Component\Translation\Loader\LoaderInterface;
use Symfony\Component\Translation\MessageCatalogue;
class MyCustomLoader implements LoaderInterface
{
public function load($resource, $locale, $domain = 'messages')
{
$catalogue = new MessageCatalogue($locale);
// de alguna forma carga algunas traducciones desde el
// directorio "resource" y luego las coloca en el catálogo
$catalogue->set('hello.world', 'Hello World!', $domain);
return $catalogue;
}
}
El método load de tu cargador personalizado es responsable de devolver una clase Symfony\Component\Translation\MessageCatalogue.
Ahora, registra tu cargador como un servicio y etiquétalo como translation.loader:
services:
main.translation.my_custom_loader:
class: Acme\MainBundle\Translation\MyCustomLoader
tags:
- { name: translation.loader, alias: bin }
<service id="main.translation.my_custom_loader" class="Acme\MainBundle\Translation\MyCustomLoader">
<tag name="translation.loader" alias="bin" />
</service>
$container
->register('main.translation.my_custom_loader', 'Acme\MainBundle\Translation\MyCustomLoader')
->addTag('translation.loader', array('alias' => 'bin'))
;
La opción alias es necesaria y muy importante: Esta define la «extensión» del archivo que se utilizará para los archivos de recursos que usa este cargador. Por ejemplo, supongamos que tienes un formato bin personalizado que necesitas cargar. Si tienes un archivo bin que contiene traducciones al Francés del dominio menssages, entonces podrías tener un archivo app/Resources/translations/messages.fr.bin.
Cuando Symfony intenta cargar el archivo bin, pasa la ruta de acceso a tu cargador personalizado como el argumento $resource a cargar. Entonces, puedes llevar a cabo cualquier lógica que necesites en ese archivo para cargar tus traducciones.
Si vas a cargar las traducciones desde una base de datos, todavía necesitas un archivo de recursos, pero bien podría estar en blanco o contener un poco de información sobre la carga de los recursos desde la base de datos. El archivo es la clave para activar el método load en tu cargador personalizado.
Propósito: Registrar una extensión de Twig personalizada.
Para habilitar una extensión Twig, añádela como un servicio regular en tu configuración, y etiquétala con twig.extension:
services:
twig.extension.your_extension_name:
class: Nombre\De\Clase\De\La\Extensión\Completamente\Cualificado
tags:
- { name: twig.extension }
<service id="twig.extension.your_extension_name" class="Nombre\De\Clase\De\La\Extensión\Completamente\Cualificado">
<tag name="twig.extension" />
</service>
$container
->register('twig.extension.your_extension_name', 'Nombre\De\Clase\De\La\Extensión\Completamente\Cualificado')
->addTag('twig.extension')
;
Para más información sobre cómo crear la clase real para la extensión de Twig, consulta el tema en la documentación de extensiones o lee el artículo del recetario: Cómo escribir una extensión Twig personalizada
Antes de escribir tus propias extensiones, echa un vistazo al Repositorio oficial de extensiones Twig el cual ya cuenta con varias útiles extensiones. Por ejemplo Intl y su filtro localizeddate que formatea una fecha según la configuración regional del usuario. Estas extensiones oficiales de Twig también se tienen que añadir como servicios normales:
services:
twig.extension.intl:
class: Twig_Extensions_Extension_Intl
tags:
- { name: twig.extension }
<service id="twig.extension.intl" class="Twig_Extensions_Extension_Intl">
<tag name="twig.extension" />
</service>
$container
->register('twig.extension.intl', 'Twig_Extensions_Extension_Intl')
->addTag('twig.extension')
;
Propósito: Registrar un servicio personalizado que cargue plantillas Twig
De manera predeterminada, Symfony sólo utiliza un Cargador Twig —Symfony\Bundle\TwigBundle\Loader\FilesystemLoader. Si necesitas cargar plantillas Twig desde otro recurso, puedes crear un servicio para el nuevo cargador y etiquetarlo con twig.loader:
services:
acme.demo_bundle.loader.some_twig_loader:
class: Acme\DemoBundle\Loader\SomeTwigLoader
tags:
- { name: twig.loader }
<service id="acme.demo_bundle.loader.some_twig_loader" class="Acme\DemoBundle\Loader\SomeTwigLoader">
<tag name="twig.loader" />
</service>
$container
->register('acme.demo_bundle.loader.some_twig_loader', 'Acme\DemoBundle\Loader\SomeTwigLoader')
->addTag('twig.loader')
;
Propósito: Crear tu propia restricción de validación personalizada.
Esta etiqueta te permite crear y registrar tu propia restricción de validación personalizada. Para obtener más información, lee el artículo del recetario: Cómo crear una restricción de validación personalizada.
Propósito: Registrar un servicio que inicia los objetos antes de validarlos.
Esta etiqueta proporciona una pieza de funcionalidad muy poco común que te permite realizar algún tipo de acción sobre un objeto justo antes de validarlo. Por ejemplo, Doctrine lo utiliza para consultar todos los datos cargados de manera diferida en un objeto antes de validarlos. Sin esto, algunos datos sobre una entidad de Doctrine parecería que hubieran «desaparecido» cuando se validan, a pesar de que este no sea realmente el caso.
Si necesitas usar esta etiqueta, solo crea una nueva clase que implemente la interfaz Symfony\Component\Validator\ObjectInitializerInterface. Luego, etiquétala como validator.initializer (que no tiene opciones).
Para un ejemplo, consulta la clase EntityInitializer en el puente de Doctrine.
