Simple event dispatcher based on PHP-DI.
This library does not aim to be general purpose library or to cover all possible use cases. What this library does aim to be is perfect choice for those who use PHP-DI and prefer to use PHP Definitions.
The goal is to create as decoupled code as possible. The code that uses the dispatcher may not know its listeners, and the other way around, the listeners may not even know that they are actually used as listeners!
EventDispatcher is available via composer:
composer require koriit/eventdispatcherThis library depends on PHP-DI and is thus affected by compatibility breaks coming from it.
Tested with PHP-DI ^6.0.
Tested with PHP-DI ^5.4.
You are encouraged to familiarize yourself with Koriit\EventDispatcher\EventDispatcherInterface and
Koriit\EventDispatcher\EventContextInterface as those two interfaces are everything you need to work
with this library.
Basic example:
// configure and build your container
$dispatcher = new EventDispatcher($container);
$listener = function (LoggerInterface $logger, Request $request) {
$logger->info($request->getMethod().' '.$request->getPathInfo());
};
$dispatcher->addListener("init", $listener, 10);
$dispatcher->dispatch("init");Naturally since we are using PHP-DI then we would create a definition for
Koriit\EventDispatcher\EventDispatcherInterface.
A listener may be anything that can be invoked by PHP-DI:
// MyClass.php
class MyClass
{
public function logRequest(LoggerInterface $logger, Request $request)
{
$logger->info($request->getMethod().' '.$request->getPathInfo());
}
}// configure and build your container
$dispatcher = $container->get(EventDispatcherInterface::class);
$dispatcher->addListener(ApplicationLifecycle::INITIALIZING, [MyClass::class, 'logRequest'], 10);
$dispatcher->dispatch(ApplicationLifecycle::INITIALIZING);Even interfaces:
// MyInterface.php
interface MyInterface
{
public function logRequest(LoggerInterface $logger, Request $request);
}// MyClass.php
class MyClass implements MyInterface
{
public function logRequest(LoggerInterface $logger, Request $request)
{
$logger->info($request->getMethod().' '.$request->getPathInfo());
}
}// configure and build your container
$dispatcher = $container->get(EventDispatcherInterface::class);
$dispatcher->addListener(InitializationEvent::class, [MyInterface::class, 'logRequest'], 10);
$dispatcher->dispatch(InitializationEvent::class, ["event" => new InitializationEvent()]);For above example to work you need to configure a definition for MyInterface, of course.
Warning:
Event dispatcher doesn't work well with listeners which implement fluent interface or allow for
method chaining. For more information, read about stopping dispatchemnt chain below.
There are 2 ways to subscribe a listener. In both cases you have to specify name of the event and calling priority. The higher the priority value the later the listener will be called. Listeners with the same priority will be called in the order they have been subscribed. You can entirely omit priority parameter as it defaults to 0.
First, by using addListener method on Koriit\EventDispatcher\EventDispatcher object.
interface EventDispatcherInterface
{
// ..
/**
* Subscribes a listener to given event with specific priority.
*
* Listener must be invokable by PHP-DI.
*
* The higher the priority value the later the listener will be called.
* Listeners with the same priority will be called in the order they have been subscribed.
*
* @param mixed $eventName
* @param mixed $listener
* @param int $priority
*/
public function addListener($eventName, $listener, $priority = 0);
// ...
}Second, by using addListeners method on Koriit\EventDispatcher\EventDispatcher object.
interface EventDispatcherInterface
{
// ..
/**
* Subscribes listeners in bulk.
*
* Listeners array is a simple structure of 3 levels:
* - At first level it is associative array where keys are names of registered events
* - At second level it is indexed array where keys are priority values
* - At third level it is simple list containing listeners subscribed to given event with given priority
*
* @param array $listeners
*
* @return void
*/
public function addListeners($listeners);
// ...
}Listeners array is a simple structure of 3 levels:
- At first level it is associative array where keys are names of registered events
- At second level it is indexed array where keys are priority values
- At third level it is simple list containing listeners subscribed to given event with given priority
Example:
// listners.php
// namespace and imports...
return [
CLIApplicationLifecycle::INITIALIZING => [
0 => [
[ConfigServiceInterface::class, 'init'],
],
1 => [
[CommandsServiceInterface::class, 'load'],
],
],
CLIApplicationLifecycle::FINALIZING => [
100 => [
function (LoggerInterface $logger, InputInterface $input, $exitCode) {
$logger->info('Returning from command `'.$input.'` with exit code '.$exitCode);
},
],
],
];// ...
$dispatcher->addListeners(include 'listeners.php');
// ...Dispatchment is a simple process of invoking all listeners subscribed to dispatched event.
interface EventDispatcherInterface
{
// ...
/**
* Dispatches an event with given name.
*
* @param mixed $eventName
* @param array $parameters
*
* @return EventContextInterface
*/
public function dispatch($eventName, $parameters = []);
// ...
}// ..
$dispatcher->dispatch(ApplicationLifecycle::INITIALIZING);If any listener in the dispatchment chain returns a value that can be evaluated as true,
the dispachment is stopped and all the remaining listeners are skipped. You can also achieve this by
calling stop on event context.
While this design simplifies the process and does not require wiring listeners with event dispatcher,
it makes it problematic to work with listeners that return values which cannot be interpreted as
success or failure. This especially holds true for methods which allow for method chaining or implement
fluent interface. To work around this problem you can use stop and ignoreReturnValue methods on
event context, though, that requires wiring your listener with event context.
Everything is a trade-off, someone once said.
Event context is simple data object holding information about the dispatchment process.
See Koriit\EventDispatcher\EventContextInterface for more information.
You can pass additional parameters to be used by invoker while injecting listener arguments by name.
// ..
$dispatcher->dispatch(InitializationEvent::class, ["event" => new InitializationEvent()]);function listener($event) {
// $event is InitializationEvent object
}There are 3 parameters injected by event dispatcher itself:
- eventName - name of the event dispatched
- eventContext - reference to the context object of current dispatchment
- eventDispatcher - reference to the event dispatcher itself; this allows for nested dispatchments
You cannot override them as using those keys in parameters array causes exception.