Historique

Les développeurs PHP ont constaté qu’ils avaient besoin de solutions standardisées pour gérer des besoins récurrents et des problèmes communs au sein de leurs applications PHP.

Ce constat a aboutit à la création en 2009 du commité PHP-FIG (PHP Framework Interoperability Group) dont l’objectif est de proposer une meilleure inter-opérabilité entre les projets PHP. Ce groupe est composé d’un comité central, de secrétaires et de membres représentants de projets et a aboutit à la mise en place de recommandations PSR (PHP Standards Recommendation).

• PSR 1 + 2 : Espaces versus tabulations
• PSR 3 : Monolog (bibliothèque standard pour la gestion de logs)
• PSR 0 + 4 : Autoloading
• PSR 7 + 15 + 17 + 18 : Interfaces HTTP immuables
• PSR 6 + 16 : Cache et cache simple
• PSR 11 : injection de dépendances
• PSR 15 : middlewares

Standardisation du répartiteur d’événements (EventDispatcher)

Problème avec le répartiteur d’événements (EventDispatcher), chaque framework avait sa propre gestion : symfony/event-dispatcher, doctrine/event-dispatcher, Laravel event dispatcher et chaque CMS également : Drupal avec des « hooks » et les événements symfony, TYPO3 avec les « hooks » et les signals, Wordpress avec des « hooks », etc.

À quoi servent ces événements ?

Ils permettent d’étendre vos librairies et applications PHP :

• notification à sens unique - « Quelque chose s’est passé et je veux vous en informer »
• amélioration d’un objet  - « Quelque chose est sur le point de se passer, faire des ajouts ou des modifications avant que je le fasse »
• collection - « Donne-moi tes choses, je vais peut-être faire quelque chose avec »
• chaîne alternative - « Quelque chose est sur le point d’arriver, vérifie si quelqu’un peut le faire »

Comment sont gérés les événements ?

Événement (Event) : c’est un message

• certains créent un objet ou utilisent des tableaux de référence
• une chaîne pour identification
• possibilité d’avoir des arguments / des propriétés

Auditeur (Listener)

• certains les appelle des observateurs ou des souscripteurs
• faire quelque chose maintenant ou peut-être plus tard (en différé)

Fournisseur d’auditeur (Listener provider)

• collecte tous les auditeurs

Répartiteur d’événement (Event Dispatcher) qui envoie le message

• appelle les auditeurs enregistrés dans le code appelant (Emitter)

Exemples :

Besoins :

• identifier un événement avec un objet PHP : pas de chaîne, d’événements anonymes, d’événements avec seulement des arguments
• séparer la répartition de l’enregistrement de l’auditeur
• immutabilité ne peut pas être assurée par les interfaces
• déterminer l’ordre d’exécution des auditeurs

Nouveau standard PSR-14 :

Un répartiteur (dispatcher) qui reçoit les événements (le message) et qui le retourne après traitement.

Un fournisseur d’auditeurs (listener provider) qui collecte les auditeurs et les injecte dans le répartiteur (dispatcher).

Qu’est-ce qu’un événement ? Une classe final (une classe qui ne peut pas être étendue).

Créer un événement et le dispatcher.

Créer un auditeur (listener).

Des événements que l’on peut stopper. Si l’auditeur a fait tout le travail, on peut stopper la propagation de l’événement.

Gestion des événements dans TYPO3 avec PSR-14

Le système d’event dispatcher a été ajouté pour étendre le comportement du core Typo3 en PHP à partir de la TYPO3 10.

Avec cette gestion des événements, on peut :

• utiliser des événements génériques EventDispatcher de n’importe où dans Typo3
• les extensions peuvent utiliser ces événements de façon identique avec TYPO3 et avec Symfony
• tous les événements Typo3 disponibles sont documentés et sous forme d’objets PHP
• les anciens « hooks » et les signal/slot d’extbase sont simplement devenus des auditeurs (listeners)

Comment ajouter un auditeur (listener) ?

Dans le fichier Configuration/Services.yaml, on va ajouter une entrée avec le tag event.listener.

• Le tag event.listener indique qu’un auditeur doit être enregistré,
• la classe personnalisée ‘MyCompany\MyPackage\EventListener\MyListener’ sert d’auditeur,
• ‘identifier’ est un nom commun qui permet d’ordonner les auditeurs, on peut utiliser pour cela les attributs ‘before’ ou ‘after’,
• si aucun attribut ‘method’ n’est donnée, la classe est gérée comme invokable et la méthode ‘__invoke()’ est appelée (méthode appelée lorsque l’on tente d’appeler un objet comme une fonction)
• ‘event’ : l’événement que l’on souhaite gérer. Depuis la version 11.3, il peut être ignoré si l’auditeur a ce type d’événement dans la signature de la méthode.

Meilleurs pratique dans TYPO3 :

1. Ajouter une classe auditeur par type d’événement et l’appeler avec ‘__invoke()’.
2. Lors de la création d’une classe événement PHP, il est recommandé de lui ajouter le suffixe Event et de la mettre dans le dossier approprié : Classes/Database/Event par exemple.
3. Les émetteurs (cœur TYPO3 ou auteurs d’extensions) doivent toujours utiliser l’injection de dépendances (DI) pour recevoir les objets de type EventDispatcher en tant qu’argument du constructeur.

On peut retrouver tous les Event Listeners enregistrés avec le module BE de configuration Typo3.

Liens :

https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Hooks/EventDispatcher/Index.html

https://www.php-fig.org/psr/psr-14/