In [part 3](https://www.garfieldtech.com/blog/psr14-part-3) of our series we looked at some common Provider patterns for [PSR-14](http://www.php-fig.org/psr/psr-14/). But the flexibility and complexity of Providers is limited only by your imagination. Today we'll look at a few more interesting examples of Providers that are all equally valid but tailored to particular use cases.
As mentioned back in part 1, PSR-14 splits the core mediator into two objects: The Dispatcher and the Provider. The Dispatcher is fairly straightforward and most implementations will be fairly simple and fairly similar.
Providers are the exact opposite; A Listener Provider has one requirement: It maps the Event object into an iterable of callables, in the order it chooses. How it does that is left up to the Provider to define, and there are dozens of possible ways.
In the last installment we discussed the overall structure of PSR-14. Today I'd like to dive into the key aspect of any event system: The Events themselves.
Various different event systems structure events in different ways. Some require that it be an object. Others it's any arbitrary value. Others it's any number of arbitrary values, depending on the Event. Some really really want pass-by-reference arrays.
For PSR-14, we chose to standardize on an object and always an object. There were three main reasons for that:
The PHP Framework Interoperability Group (PHP-FIG) has released a number of new specifications in the last year. The latest, PSR-14, covers Event Dispatching. Like many PSRs it's a fairly small spec, at the end of the day, but intended to be high-impact.
In this series of posts I want to cover what PSR-14 is and does (and what it isn't and doesn't), and how to best leverage it in your projects as it gets deployed more widely.
(I'm sure that's a bunch of gibberish for the non-developers in the room, but it matters to the PHP developers, I swear...)
After a longer than intended delay, I'm happy to announce the 3.0 release of my Crell/ApiProblem library.
ApiProblem is a small, self-contained library for modeling IETF RFC 7807 "Problem Details" messages. (I know, more gibberish.) That is, it makes it easier for PHP developers to build a message for their API servers to handle cases where Something Bad Happened(tm).
2015 is turning into a watershed year for PHP. Many projects either have or will release new major versions, including Zend Framework, Symfony, Laravel, Guzzle, Drupal, Slim, and many others. And of course there's PHP 7 itself, coming this fall.
I'll talk more on those later, but for the moment I want to focus on one other major new development this year: PSR-7.