Blog

I've just released version 2.0 of Crell/Tukio! Available now from your favorite Packagist.org. Tukio is a feature-complete, easy to use, robust Event Dispatcher for PHP, following PSR-14. It began life as the PSR-14 reference implementation.

Tukio 2.0 is almost a rewrite, given the amount of cleanup that was done. But the final result is a library that is vastly more robust and vastly easier to use than version 1, while still producing near-instant listener lookups.

Some of the major improvements include:

• It now uses Topological sorting internally, rather than priority sorting. Both are still supported, but the internal representation has changed. The main benefits are cycle detection and support for multiple before/after rules per listener.
• The API has been greatly simplified, thanks to PHP 8 and named arguments. It's now down to essentially two methods -- listener() and listenerService(), both of which should be used with named arguments for maximum effect. The old API methods are still supported, but deprecated to allow users to migrate to the new API.
• Tukio can now auto-derive more information about your listeners, making registration even easier.
• It now uses the powerful Crell/AttributeUtils library for handling attribute-based registration. That greatly simplified a lot of code while making several new features easy.
• Attributes are now supported on the class level, not just method. That makes building single-method listener services trivially easy.

In early 2019, the PHP Framework Interoperability Group (PHP-FIG) released PSR-14, the Event Dispatcher specification. At the time I posted a long series of blog posts detailing PSR-14 in all its glory.

After discussing with a few other FIG folks, I've decided to release that blog series as a small ebook. Mainly that is to provide an easy single-point-of-reference for those who want to really understand PSR-14. Also, it serves as a simple fundraiser.

The book itself is available completely free, as the original blog posts were. However, you can also purchase a copy if you want to help support my work on the Framework Interoperability Group and Open Sourcing Mental Illness. OSMI is a non-profit organization that works to raise awareness of and research information about mental health challenges in the tech community. 50% of all royalties for this book are automatically donated to OSMI to support their vital work.

If you just want to grab a copy for free, go for it. If you are able to, though, I would encourage you to pay what you're comfortable with to support both my Open Source efforts and OSMI.

Back in January 2017, the PHP Framework Interoperability Group (FIG) reviewed and passed PSR-11, the "Container Interface" specification. It was a very simplistic 2-method interface for Dependency Injection Containers, which had been worked on for some time by a small group. (This was before FIG had formal Working Groups, but "container-interop" was one of the effectively proto-Working Groups that were floating about.)

PSR-11 passed overwhelmingly, 23 to 1 out of the FIG member projects at the time. The lone holdout was Drupal, for which at the time I was the voting representative.

Two and a half years later, I will say I was wrong, and PSR-11 has been a net-win for PHP.

So far we've looked at a number of complete, practical examples of using PSR-14 Events in various ways, both conventional and unconventional. In our final (probably) installment, I want to offer a highly unconventional but still practical use of PSR-14 that really shows off just how flexible Events can be: Layered caching.

"But wait, isn't caching the realm of PSR-6 and PSR-16?" Yes. Yes it is. But neither of those offer a built-in way to compose multiple cache backends together. It's certainly possible, but doing so is left as an exercise for the implementer. Let's use PSR-14 to get some exercise.

We continue our exploration of PSR-14's potential with a guest post. Cees-Jan Kiewiet was the Sponsor of PSR-14 (meaning the member of the Core Committee who bridged from the Working Group to the Core Committee), and is on the core team for ReactPHP. One wouldn't think there's any use cases for PSR-14 in an async environment like React, but one would be wrong.

Here's Cees-Jan with an explanation:

One of the long-running debates while designing PSR-14 was how to handle events that were inherently mono-directional. Often, a library will trigger an Event that is, from its point of view, entirely informational. The Event object it fires has no mutator methods so Listeners have no way to interact with each other, which means that the order Listeners run in is irrelevant. It also means Listeners can pass no data back to the emitting library, which means the result of the Event can have no impact on the Emitter's further logic.

This special case opens up more options for how to execute the Listeners. Because there is guaranteed no communication from Listener to Listener or from Listener to Emitter, it's safe to run the Listeners concurrently. In fact, it's safe to run the Listeners concurrently with the Emitter. The Emitter doesn't even need to wait for the Listeners to fire before continuing.

In Content Management Systems and similar highly-configurable applications, a common pattern is to have a registration mechanism of some sort. That is, some part of the system asks other parts of the system "give me a list of your Things!", and then modules/extensions/plugins (whatever the system calls them) can incrementally build up that list of Things, which the caller then does something with. Those Things can be defined by the extension, or they can be defined by user-configuration and turned into a Thing definition by the module. Both are valid and useful, and can be mixed and matched.

This pattern lends itself very well to an Event system like PSR-14, and in fact the "give me a list of Things" pattern was one of the explicit use cases the Working Group considered. Today let's look at how one could easily implement such a mechanism.

So far in our 5 part series we've dug into the details of Events, Dispatchers, and Providers. An awful lot of flexibility can be had from just three simple methods. But how does it work out in practice?

In today's installment I want to start showing examples of real-world (ish) use cases that can benefit from this design. For these examples I will be using Tukio, my stand-alone PSR-14 implementation, but all will work just as well with any PSR-14 implementation, by design.

In part 3 of this series we looked at the more common patterns of Providers that may be used with a PSR-14 Event Dispatcher. In part 4 we looked at some more complex cases of Providers. Today, we'll bring them all together: Literally.

Recall that a Provider is responsible only for receiving an Event and returning a list of callables that it believes should be invoked on it, in the order it decides (if it cares). How it does that is up to the implementation. In fact, it's not even required to do so itself at all. A Provider can defer that decision to another Provider if it wishes, or, critically, to multiple Providers.

In part 3 of our series we looked at some common Provider patterns for 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.