PSR-14: el evento principal en PHP

El año pasado, PHP-FIG , el Grupo de Conceptos de Compatibilidad de PHP , lanzó varias especificaciones nuevas. El último, PSR-14 , está dedicado al despacho de eventos. Al igual que otros PSR, esta es una especificación local, pero tiene un gran impacto en muchos aspectos de la estandarización.

De un traductor: Esta es la traducción de la primera parte de una serie de publicaciones en la que Larry (Crell) Garfield, uno de los miembros de PHP-FIG, explica qué es PSR-14, de qué es capaz y qué no es, y cuál es la mejor manera de usarlo. sus proyectos

Propósito

El despacho de eventos se ha utilizado durante mucho tiempo en muchos idiomas. Si alguna vez ha utilizado EventDispatcher en Symfony , el sistema de eventos en Laravel , los ganchos en Drupal, el Administrador de eventos en el marco Zend, el paquete League \ Event o algo así, entonces comprende de qué se trata.

En un sentido general, todos estos sistemas son una forma de "mediador-observador". Una pieza de código envía un mensaje del tipo - "evento", y el intermediario lo envía a otras piezas de código individuales - "oyentes". A veces la señal se dirige solo en una dirección, a veces el "oyente" puede de alguna manera transmitir datos a la persona que llama. Por supuesto, todos son diferentes y no son muy compatibles entre sí.

Este es un problema para las bibliotecas independientes que desean conectarse a varias bibliotecas y aplicaciones. Muchas bibliotecas se pueden ampliar enviando eventos de una forma u otra para que otro código pueda contactarlos. Pero esa capa intermedia es, de hecho, propietaria. La biblioteca que ejecuta Symfony EventDispatcher se fusiona con Symfony. Luego, usarlo en otro lugar requiere instalar EventDispatcher y conectarse a las bibliotecas del programa. La biblioteca que llama al sistema de enlace desde Drupal module_invoke_all() se vincula a Drupal. Y así sucesivamente.

El objetivo de PSR-14 es eliminar las dependencias de las bibliotecas. Esto permite que las bibliotecas se expandan a través de una capa común delgada y luego faciliten su transferencia a otro entorno sin esfuerzo y gastos adicionales, por ejemplo, en Symfony, Zend Framework, Laravel, TYPO3, eZ Platform o Slim. Mientras el entorno tenga compatibilidad con el PSR-14, todo funcionará.

Especificación

Como ya se mencionó, la especificación es bastante ligera. Estas son tres interfaces en un método y una meta descripción de cómo usarlas. Todo es simple y conveniente. A continuación se muestra el código para estas interfaces (sin comentarios para ahorrar espacio).

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

Los dos primeros son el núcleo de la especificación. StoppableEventInterface es una extensión a la que volveremos más tarde.

Creo que EventDispatcher familiar para la mayoría de ustedes, es solo un objeto con el método al que pasan el evento, el intermediario del que ya hablaron. Sin embargo, el evento en sí no está definido: puede ser cualquier objeto PHP . Más sobre esto más tarde.

La mayoría de las implementaciones existentes tienen un objeto o conjunto de funciones que actúan como intermediario o despachador y un lugar para registrar el código que recibe el evento (oyentes). Para PSR-14, dividimos deliberadamente estas dos responsabilidades en objetos separados. El despachador recibe una lista de oyentes del objeto proveedor que forma esta lista.

¿De dónde obtiene el proveedor la lista de oyentes? Si, donde quiere! Hay mil millones y una forma de conectar al oyente y el evento, todos ellos son absolutamente válidos e incompatibles. Al principio, decidimos que la estandarización de "One True Way" para el registro de estudiantes sería demasiado limitada. Sin embargo, al estandarizar el proceso de conectar al oyente al despachador, puede obtener una excelente flexibilidad sin obligar al usuario a hacer algo extraño e incomprensible.

Además, el código no indica qué es el oyente. Puede ser cualquier fragmento de PHP capaz de percibir señales: una función, una función anónima, un método de objeto, cualquier cosa. Dado que el objeto llamado puede hacer cualquier cosa, está permitido tener, como oyente, una función anónima que realiza la carga retrasada de un servicio desde un contenedor DI y llama al método en el servicio, que en realidad contiene el código de escucha.

En resumen, el despachador es una API simple y fácil para autores de bibliotecas. Los proveedores de escucha ofrecen una API robusta y flexible para integradores de marcos, y la relación entre el despachador y el proveedor los une.

Ejemplo simple

En términos generales, el esquema de combinar todas las partes en un todo se verá más o menos así.

 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); 

Este pequeño fragmento de código ofrece grandes oportunidades y es muy flexible. En los siguientes artículos, hablaremos en detalle acerca de sus propiedades, analizaremos algunas soluciones estructurales y consideraremos las muchas formas de usar tales eventos livianos.

Código

PSR-14 ya es compatible con los principales marcos y aplicaciones.

• Matthew Weier O'Phinney ya se ha comprometido a introducir soporte para PSR-14 en zend-eventmanager 4.0 en el marco de Zend.
  
• Symfony anunció recientemente cambios en EventDispatcher para compatibilidad con PSR-14, que brindará soporte completo en 5.0 / 5.1.
  
• El marco Yii anunció su intención de integrar el PSR-14 en la versión 3.0 .
  
• Benni Mack de TYPO3 CMS dijo que en la próxima versión de TYPO3, todos los conceptos existentes de trampa + señal / ranura admitirán el PSR-14.
  

PSR-14 también tiene tres implementaciones independientes totalmente funcionales que ya puede usar en cualquier aplicación.

• Tukio por Larry Garfield, autor de este artículo.
  
• Despachador de eventos Phly por Matthew Weier O'Phinney.
  
• Kart de Benni Mack, que funciona como un complemento incrustado.
  

El autor agradece a todo el grupo de trabajo de PSR: Larry Garfield , Cees-Jan Kiewiet , Benjamin Mack , Elizabeth Smith , Ryan Weaver , Matthew Weier O'Phinney . A lo largo del trabajo, el proceso fue extremadamente productivo: todos trabajaron juntos, colectivamente, como debería ser. El resultado es agradable, y me gustaría que todos los esfuerzos adicionales en el trabajo conjunto sobre arquitectura sean tan productivos.

Puede encontrar más detalles en el original de la siguiente parte y en la documentación o el 17 de mayo en PHP Rusia . La segunda opción es atractiva por varias razones. Por ejemplo, el jefe del Comité del Programa, Alexander ( samdark ) Makarov, es uno de los que presentó el PSR-14 en Yii. Y, en principio, la composición del Comité del Programa y los oradores es increíblemente fuerte, casi no hay ningún tema de la esfera del uso profesional de PHP que no pueda discutirse en esta conferencia.