Скачать или смотреть Symfony6 et Symfony7 Techwall #72 Le système d'évènement l'EventSubscriber

Symfony6 et Symfony7 Techwall #72 Le système d'évènement l'EventSubscriber

https://github.com/aymensellaouti/sf6...

Une deuxième méthode d’écoute sur des événements est l’utilisation des EventSubscriber.
Un eventSubscriber est une classe qui définit une ou plusieurs méthodes qui écoute sur un ou plusieurs événements.
La différence majeure avec les EventsListener est que les Subscribers connaissent toujours les événements sur lesquels ils écoutent au contraire des EventListener.

Un eventSubscriber est une classe qui implémente l’interface EventSubscriberInterface.
Cette interface nous demande d’implémenter la méthode getSubscribedEvents.
Cette méthode doit retourner un tableau des noms des événements auxquels le subscriber veut écouter. Chaque élément du tableau peut avoir comme clé le nom de l’événement à écouter et comme valeur une des options suivantes :
Le nom de la méthode à appeler (la priorité à comme valeur par défaut 0)
['eventName' = 'methodName']
Un tableau avec le nom de la méthode à appeler et la priorité
['eventName' = ['methodName', $priority]]
Un tableau de tableau composé des deux précédentes formes
['eventName' = [['methodName1', $priority], ['methodName2']]]

Les Listeners et les Subscribers peuvent être utilisés indistinctement dans la même application.
La décision d'utiliser l'un ou l'autre d'entre eux est généralement une question de goût personnel. Cependant, il y a quelques avantages mineurs pour chacun d'eux :

Les Subscribers sont plus faciles à réutiliser car la connaissance des événements est conservée dans la classe plutôt que dans la définition du service. C'est la raison pour laquelle Symfony utilise les Subscribers en interne ;
Les Listeners sont plus flexibles car les bundles peuvent activer ou désactiver chacun d'eux de manière conditionnelle en fonction d'une valeur de configuration.


Le système d’événements de Symfony utilise les priorités afin de savoir quel ordre d’écouteur déclencher.
La propriété ayant la valeur la plus haute sera exécuté en premier.
Le tag priority vous permet de définir la priorité de votre écouteur


Afin de finaliser notre système, et après avoir créer l’événement et le dispatcher, il faut permettre aux intéressés par cet événement de l’écouter, se greffer dessus et exécuter le traitement souhaité.
Il y a deux méthodes pour permettre cet écoute :
Créer un EventListener
Créer un EventSubscriber

Afin d’utiliser un EventListner, il faut créer un service et le tagger.
Le tag permettant de dire à l’EventDispatcher voici un EventListener est le tag name avec la valeur kernel.event_listener.
Le tag permettant d’identifier l’événement à écouter est event
Le tag permettant d’identifier la méthode à exécuter est method


Afin d’avoir un code extensible et basée sur des plugins qu’on peut ajouter avant ou après l’exécution d’un code, Symfony nous propose le composant EventDispatcher.
L’idée est de pouvoir ajouter des plugins avec des fonctionnalités qu’on peut greffer sans interférer dans les autres plugins.

L’EventDispatcher de Symfony utilises deux patron de conception pour le faire : Le Médiateur et l’observateur.

L’observateur va nous permettre de faire en sorte qu’un ou plusieurs observateurs sont intéressés par un ou plusieurs sujets. Chaque fois que quelque chose de neuf se produit dans un sujet, tous ses observateurs sont notifiés.

Le médiateur (La classe EventDispatcher) va nous permettre d’encapsuler la manière avec laquelle cet ensemble d’objets vont interagir. Il sera l’intermédiaire.

Pour résumer, le système d’événements de Symfony se base sur :

Un événement (Event)

Un gestionnaire d’événement (Dispatcher)

Les écouteurs sur les événement (Listner)