3.12. Sobre o Event Manager

Nesta seção, forneceremos algumas informações avançadas sobre o service manager. Você pode com relativa segurança pular esta seção, no entanto, consulte se você pretende implementar alguns events listeners em seu site.

Anteriormente neste capítulo, mencionamos que o ciclo de vida da aplicação consiste em eventos. Uma classe pode desencadear um evento e outras classes podem listen (ouvir) eventos. Tecnicamente, desencadear um evento significa apenas chamar método de "callback" de outra classe. O service manager é implementado dentro de o componente Zend\EventManager.

ZF3 (e particularmente seu componente Zend\Mvc) dificilmente depende de eventos para operar, e, por causa disso, seu código-fonte é uma combinação de events listeners, o que é bastante difícil de entender. Felizmente, na maioria dos casos, você não precisa entender como o ZF3 dispara e lida com eventos internamente, você só precisa para entender o que é evento, quais eventos estão presentes no ciclo de vida da aplicação e qual é a diferença entre o usual service manager e shared event manager.

3.12.1. Event & MvcEvent

Um event é tecnicamente uma instância da classe Zend\EventManager\Event. Um evento basicamente pode ter pelo menos as seguintes partes:

• name - identifica exclusivamente o evento;
• target - normalmente é um ponteiro para o objeto que acionou o evento;
• e params - argumentos específicos do evento passados ​​aos events listeners.

É possível criar tipos personalizados de eventos estendendo a classe Event. Por exemplo, o componente Zend\Mvc define o tipo de evento personalizado chamado Zend\Mvc\MvcEvent, que estende a classe Event e adiciona várias propriedades e métodos necessário para o componente Zend\Mvc funcionar.

3.12.2. EventManager & SharedEventManager

É importante entender a diferença entre o event manager usual e o event manager shared.

O event manager comum não é armazenado como singleton no service manager. Toda vez que você solicita o serviço EventManager do service manager, você recebe uma nova instância dele. Isso é feito por motivos de privacidade e desempenho:

• Presume-se, por padrão, que os eventos de acionamento da classe serão solicitados e salvos em algum lugar seu próprio event manager privado, porque não quer que outras classes ouvir automaticamente esses eventos. Considera-se que os eventos acionados pela classe pertencem a essa classe de forma privada.

• Se alguém fosse capaz de ouvir qualquer evento desencadeado por qualquer classe, haveria um desempenho infernal - muitos ouvintes de eventos seriam invocados, aumentando assim o tempo de carregamento da página. É melhor evitar isso mantendo os eventos privados.

Mas, no caso de alguém intencionalmente precisar ouvir os eventos dos outros, há um event manager compartilhado especial. O SharedEventManager o serviço é armazenado no service manager como um singleton, portanto, você pode ter certeza de que todos terão a mesma instância dele.

Alguns exemplos práticos de como ouvir e reagir a um evento podem ser encontrados no capítulo Criando um novo Módulo e em User Management, Authentication & Access Filtering.