En esta sección daremos información avanzada sobre el administrador de eventos. Podemos saltar esta sección con relativa seguridad, sin embargo será necesario leerla si planeamos implementar algunos oyentes de eventos (event listeners) avanzados en nuestro sitio web.
Anteriormente en este capítulo hemos mencionado que el ciclo de vida de la aplicación
consiste en eventos. Una clase puede lazar un evento y otra clase puede escuchar
los eventos. Técnicamente, lanzar un evento significa con exactitud llamar a otro
método callback de una clase. El administrador de eventos se implementa dentro del
componente Zend\EventManager
.
ZF3 (y particularmente su componente
Zend\Mvc
) depende de eventos para funcionar, como consecuencia su código es una combinación de oyentes de eventos que son algo difíciles de entender. Por fortuna, en la mayoría de los casos no necesitamos entender como ZF3 lanza y maneja eventos internamente, solo necesitamos entender lo que es un evento, que eventos están presentes en una aplicación y cual es la diferencia entre un administrador de eventos usual y un administrador de eventos compartidos.
Un evento es técnicamente una instancia de la clase Zend\EventManager\Event
. Un
evento puede en principio tener al menos las siguientes partes:
Es posible crear tipos de eventos a la medida extendiendo a la clase Event
.
Por ejemplo, el componente Zend\Mvc
define un tipo de evento a la medida llamado
Zend\Mvc\MvcEvent
que extiende a la clase Event
y agrega varias propiedades
y métodos necesarios para el funcionamiento de Zend\Mvc
.
Es importante entender la diferencia entre el usual administrador de eventos y el administrador de eventos compartido.
El administrador de eventos usual no es guardado como un singleton en el administrador
de servicios. Cada vez que pedimos el servicio EventManager
desde el administrador de
servicios recibimos una nueva instancia de él. Esto se hace por privacidad y
rendimiento:
Se asume por defecto que la clase lanzadora de eventos pedirá y guardará en algún lugar su propio administrador de eventos privado porque no se quiere que otras clases escuchen automáticamente estos eventos. Los eventos lanzados por la clase se consideran como pertenecientes a la clase privadamente.
Si alguien quisiera ser capaz de escuchar cualquier evento lanzado por alguna clase, sería un infierno, demasiados oyentes de eventos serían invocados, incrementando el tiempo de carga de la página. Es mejor evitar esto manteniendo eventos privados.
Pero en caso de que alguien intencionalmente necesite escuchar a otro evento, existe
un administrador especial para eventos compartidos. El servicio SharedEventManager
se guarda en el administrador de servicios como un singleton, de esta manera podemos
estar seguros de que todos tendrán la misma instancia de él.
Con el SharedEventManager
podemos fijar un oyente a un evento privado lanzado por
determinada clase (o varias clases). Para esto debemos especificar el o los identificadores
únicos de la clase que quieras escuchar. ¡Así de simple!
Algunos ejemplos prácticos de como escuchar y actuar frente a un evento se pueden encontrar en los capítulos Crear un Nuevo módulo y Administración de Usuarios, Autenticación y Filtro de Acceso.