Symfony6 Techwall #71 Le système d'évènement Les évènements du cycle de vie de la requête

Votre vidéo commence dans 10
Passer (5)
Formation gratuite en FR pour les membres inscrits sur les sites de vidéos

Merci ! Partagez avec vos amis !

Vous avez aimé cette vidéo, merci de votre vote !

Ajoutées by admin
69 Vues
Symfony6 Techwall #71 Le système d'évènement Les évènements du cycle de vie de la requête

https://github.com/aymensellaouti/sf6Techwall

Symfony se définit comme étant un Framework HTTP Request-Response
Durant la prise en charge de la requête HTTP, Symfony dispatche quelques événements informant sur le cycle de vie de votre requête.
Vous pouvez donc vous greffer sur ces événements et modifier comment la requête est gérée et comment la réponse est retournée.

Les événements du noyau de Symfony sont :
kernel.request
kernel.controller
kernel.controller_arguments
kernel.view
kernel.response
kernel.finish_request
kernel.terminate
kernel.exception

Chaque événement dispatché par le HttpKernel hérite de la classe KernelEvent et fournit les fonctionnalités suivantes :
getRequestType() qui returns le type de la requête (principale ou secondaire).
getKernel() qui retourne le Kernel générant la requête.
getRequest() retourne la requête actuelle
isMainRequest() vérifie si c’est la requête principale
kernel.request
Cet évènement est déclenché très tôt dans la gestion d'une requête
Son objectif principale est généralement de :
Initialiser une partie du système
Modifier la requête avant d’arriver au contrôleur.
Retourner une réponse (Par exemple en cas d’absence de droit d’accès)
Le routeur par exemple écoute à cet événement puis il injecte à la requête un attribut _controller contenant les informations sur le contrôleur à appeler.
Si un des listener définit une réponse, les listeners suivants ne seront pas exécutés.
kernel.controller
Cet évènement est déclenché après que le contrôleur à exécuter ait été défini.
Son objectif est de :
Initialiser quelques parties du système après que certaines parties soient déjà détectées (routeur, controlleur)
permettre à un listener de modifier le contrôleur à exécuter.
C’est la par exemple que travaille le ParamConvertor.

kernel.view
Cet évènement est déclenché si le contrôleur ne retourne pas un Objet Response.
Le rôle des écouteurs à cet événement est de récupérer la valeur de retour afin de créer un objet Response.
kernel.response
Cet évènement est déclenché après le renvoi de la réponse.
Ceci vous permet de modifier la réponse.
Vous pouvez par exemple ajouter ou modifier les headers, les coockies ou même changer le contenu en y ajoutant du code Js par exemple.

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)
Catégories
Evenements

Ajouter un commentaire

Commentaires

Soyez le premier à commenter cette vidéo.