3.12. À propos du gestionnaire d'événements

Dans cette section, nous allons donner quelques informations sur le gestionnaire d'événements. Vous pouvez ignorer cette section de manière relativement sûre mais référez-vous à celle-ci si vous prévoyez d'implémenter des écouteurs d'événements un peu plus poussés sur votre site.

Auparavant dans ce chapitre nous avons mentionné que le cycle de vie de l'application est constitué d'événements. Une classe peut déclencher un événement et d'autres classes peuvent écouter des événements. Techniquement, déclencher un événement signifie simplement appeler une autre méthode de "callback" de classe. La gestion des événements est implémentée dans le composant Zend\EventManager.

ZF3 (et en particulier son composant Zend\Mvc) ne dépend que très peu des événements pour fonctionner, et de ce fait, son code source est une combinaison d'écouteurs d'événements qui est plutôt difficile à comprendre. Heureusement, dans la plupart des cas, vous n'avez pas besoin de comprendre comment ZF3 déclenche et gère les événements en interne, il vous suffit de comprendre de quel événement il s'agit, quels événements sont présents dans le cycle de vie de l'application et quelle est la différence entre gestionnaire d'événements et gestionnaire d'événements partagés.

3.12.1. Événements & MvcEvent

Un événement est techniquement une instance de la classe Zend\EventManager\Event. Un événement a au moins les propriétés suivantes :

• name - identifie de manière unique l'événement;
• target - c'est un pointeur vers l'objet qui a déclenché l'événement;
• et params - les arguments spécifiques aux événements transmis aux écouteurs d'événement.

Il est possible de créer des types d'événements personnalisés en étendant la classe Event. Par exemple, le composant Zend\Mvc définit le type d'événement personnalisé nommé Zend\Mvc\MvcEvent, qui étend la classe Eventet ajoute plusieurs propriétés et méthodes nécessaires pour que le composant Zend\Mvc fonctionne.

3.12.2. Gestionnaire d'événements et gestionnaire d'événements partagés

Il est important de comprendre la différence entre le gestionnaire d'événements classique et le gestionnaire d'événements partagés*.

Le gestionnaire d'événements classique n'est pas stocké en tant que singleton dans le gestionnaire de service. Chaque fois que vous demandez le service EventManager à partir du gestionnaire de services, vous recevez une nouvelle instance. Cela pour des raisons de confidentialité et de performance :

• Il est supposé par défaut que les événements déclencheurs de la classe demanderont et enregistreront quelque part leur propre gestionnaire d'événements privé, car il ne veulent pas que les autres classes écoutent automatiquement ces événements. Les événements déclenchés par la classe sont supposés appartenir à cette classe en privé.

• Si n'importe qui pouvait écouter n'importe quel événement déclenché par n'importe quelle classe, il y aurait un enfer de performance - trop d'écouteurs d'événements seraient invoqués, augmentant ainsi le temps de chargement de la page. Il est préférable d'éviter ca en gardant les événements privés.

Mais, dans le cas où quelqu'un a intentionnellement besoin d'écouter les événements des autres, il existe un gestionnaire d'événements partagés. Le service SharedEventManager est stocké dans le gestionnaire de services sous la forme d'un singleton. Vous pouvez donc être sûr que tout le monde aura la même instance.

Avec SharedEventManager, vous pouvez lier un écouteur à des événements privés déclenchés par certaines (ou plusieurs) classes. Vous spécifiez le(s) identificateur(s) de classe que vous souhaitez écouter.

Vous trouverez des exemples pratiques d'écoute et de réaction à un événement dans le chapitre Création d'un nouveau module et dans le chapitre Gestion des utilisateurs, authentification et filtrage des accès.