PSR-14 - l'événement principal en PHP

L'an dernier, PHP-FIG , le groupe de concepts de compatibilité PHP , a publié plusieurs nouvelles spécifications. Le dernier, PSR-14 , est dédié à la répartition des événements. Comme d'autres PSR, il s'agit d'une spécification locale, mais elle a un impact important sur de nombreux aspects de la normalisation.

D'après un traducteur: il s'agit de la traduction de la première partie d'une série de publications dans lesquelles Larry (Crell) Garfield, l'un des membres de PHP-FIG, explique ce qu'est le PSR-14, de quoi il est capable et de quoi il ne s'agit pas, et quelle est la meilleure façon de l'utiliser dans leurs projets.

But

La répartition des événements est utilisée depuis longtemps dans de nombreuses langues. Si vous avez déjà utilisé EventDispatcher dans Symfony , le système d'événements dans Laravel , les hooks dans Drupal, le gestionnaire d'événements dans le framework Zend, le package League \ Event , ou quelque chose comme ça, alors vous comprenez de quoi il s'agit.

D'une manière générale, tous ces systèmes sont une forme de «médiateur-observateur». Un morceau de code envoie un message du type - "événement", et l'intermédiaire l'envoie à d'autres morceaux de code individuels - "écouteurs". Parfois, le signal n'est dirigé que dans une seule direction, parfois «l'auditeur» peut en quelque sorte transmettre des données à l'appelant. Bien sûr, ils sont tous différents et peu compatibles les uns avec les autres.

Il s'agit d'un problème pour les bibliothèques autonomes qui souhaitent se connecter à diverses bibliothèques et applications. De nombreuses bibliothèques peuvent être développées en envoyant des événements sous une forme ou une autre afin qu'un autre code puisse les contacter. Mais une telle couche intermédiaire est, en fait, propriétaire. La bibliothèque qui exécute Symfony EventDispatcher est ensuite fusionnée avec Symfony. Pour l'utiliser ensuite ailleurs, vous devez installer EventDispatcher et vous connecter aux bibliothèques du programme. La bibliothèque qui appelle le système de liaison depuis Drupal module_invoke_all() est ensuite liée à Drupal. Et ainsi de suite.

Le but du PSR-14 est de débarrasser les bibliothèques de cette dépendance. Cela permet aux bibliothèques de s'étendre à travers une couche commune mince, puis de faciliter leur transfert vers un autre environnement sans effort ni frais supplémentaires, par exemple, dans Symfony, Zend Framework, Laravel, TYPO3, eZ Platform ou Slim. Tant que l'environnement est compatible avec le PSR-14, tout fonctionnera.

Spécification

Comme déjà mentionné, la spécification est assez légère. Ce sont trois interfaces dans une méthode et une méta description de la façon de les utiliser. Tout est simple et pratique. Vous trouverez ci-dessous le code de ces interfaces (aucun commentaire pour économiser de l'espace).

 namespace Psr\EventDispatcher; interface EventDispatcherInterface { public function dispatch(object $event); } interface ListenerProviderInterface { public function getListenersForEvent(object $event) : iterable; } interface StoppableEventInterface { public function isPropagationStopped() : bool; } 

Les deux premiers sont au cœur de la spécification. StoppableEventInterface est une extension à laquelle nous reviendrons plus tard.

Je pense que EventDispatcher familier à la plupart d'entre vous - c'est juste un objet avec la méthode à laquelle vous transmettez l'événement - l'intermédiaire dont vous avez déjà parlé. L'événement lui-même, cependant, n'est pas défini - il peut s'agir de n'importe quel objet PHP . Plus d'informations à ce sujet plus tard.

La plupart des implémentations existantes ont un objet ou un ensemble de fonctions qui agissent comme intermédiaire ou répartiteur et un endroit pour enregistrer le code qui reçoit l'événement (écouteurs). Pour PSR-14, nous avons délibérément divisé ces deux responsabilités en objets distincts. Le répartiteur reçoit une liste d'écouteurs de l'objet fournisseur qui compose cette liste.

D'où le fournisseur obtient-il la liste des auditeurs? Oui, où veut-il! Il y a un milliard et une façon de connecter l'auditeur et l'événement, tous sont absolument valides et incompatibles. Au début, nous avons décidé que la standardisation de la «One True Way» pour l'inscription des étudiants serait trop limitée. Cependant, en standardisant le processus de connexion de l'auditeur au répartiteur, vous pouvez obtenir une excellente flexibilité sans forcer l'utilisateur à faire quelque chose d'étrange et d'incompréhensible.

En outre, le code n'indique pas ce qu'est l'auditeur. Il peut s'agir de n'importe quel fragment PHP capable de percevoir le signal: une fonction, une fonction anonyme, une méthode objet, n'importe quoi. Puisque l'objet appelé peut faire n'importe quoi, il est permis d'avoir, en tant qu'écouteur, une fonction anonyme, qui effectue un chargement différé d'un service à partir d'un conteneur DI et appelle la méthode dans le service, qui contient en fait le code d'écoute.

En bref, le répartiteur est une API simple et facile pour les auteurs de bibliothèques. Les fournisseurs d'écoute offrent une API robuste et flexible pour les intégrateurs de framework, et la relation entre le répartiteur et le fournisseur les rassemble.

Exemple simple

En termes généraux, le schéma de combinaison de toutes les parties en un tout ressemblera à ceci.

 class Dispatcher implements EventDispatcherInterface { public function __construct(ListenerProviderInterface $provider) { $this->provider = $provider; } public function dispatch(object $event) { foreach ($this->provider->getListenersForEvent($event) as $listener) { $listener($event); } return $event; } } $dispatcher = new Dispatcher($provider); $event = new SomethingHappened(); $dispatcher->dispatch($event); 

Ce petit morceau de code offre de grandes opportunités et il est très flexible. Dans les articles suivants, nous parlerons en détail de ses propriétés, analyserons certaines solutions structurelles et examinerons les nombreuses façons d'utiliser de tels événements légers.

Code

Le PSR-14 est déjà pris en charge par les principaux frameworks et applications.

• Matthew Weier O'Phinney s'est déjà engagé à introduire le support du PSR-14 dans zend-eventmanager 4.0 dans le framework Zend.
  
• Symfony a récemment annoncé des changements à EventDispatcher pour la compatibilité avec PSR-14, qui offrira une prise en charge complète dans 5.0 / 5.1.
  
• Le framework Yii a annoncé son intention d'intégrer le PSR-14 dans la version 3.0 .
  
• Benni Mack de TYPO3 CMS a déclaré que dans la prochaine version de TYPO3, tous les concepts trap + signal / slot existants prendront en charge le PSR-14.
  

Le PSR-14 dispose également de trois implémentations indépendantes entièrement fonctionnelles que vous pouvez déjà utiliser dans n'importe quelle application.

• Tukio de Larry Garfield, auteur de cet article.
  
• Phly Event Dispatcher par Matthew Weier O'Phinney.
  
• Kart de Benni Mack, qui fonctionne comme un plugin intégré.
  

L'auteur remercie l'ensemble du groupe de travail PSR: Larry Garfield , Cees-Jan Kiewiet , Benjamin Mack , Elizabeth Smith , Ryan Weaver , Matthew Weier O'Phinney . Tout au long du travail, le processus a été extrêmement productif: tout le monde a travaillé ensemble, collectivement, comme il se doit. Le résultat est agréable et j'aimerais que tous les efforts supplémentaires dans le travail conjoint sur l'architecture soient aussi productifs.

Vous pouvez trouver plus de détails soit dans l'original de la partie suivante et la documentation ou le 17 mai chez PHP Russie . La deuxième option est intéressante pour plusieurs raisons. Par exemple, le chef du Comité du programme, Alexander ( samdark ) Makarov, fait partie de ceux qui ont introduit le PSR-14 à Yii. Et en principe, la composition du comité du programme et des conférenciers est incroyablement forte, il n'y a pratiquement aucun sujet du domaine de l'utilisation professionnelle de PHP qui ne puisse être discuté lors de cette conférence.