If you look at my previous post on the ZF2 EventManager class you might be tempted to think that you are limited only to listening to events for local instances of the event manager. But no, my friend, you would be wrong. The event manager actually provides access to a sort of global event manager. But it's more than that. This global event manager allows you to listen in on events for various targets.

He includes an example of how to use the EventManager in a specific namespace that's triggered based on a custom event. He attaches a custom class, "cls2", to a listener on his "ns1/cls1" class.

Zend Framework 2's EventManager is a key component of the framework which is used for the core MVC system. The EventManager allows a class to publish events that other objects can listen for and then act when the event occurs. The convention within Zend Framework 2 is that any class that triggers events composing its own EventManager.

He starts with some terminology to get everyone on the same page (listener, event, EventManager) and includes an example of its use in setting up a "PhotoMapper" object showing how to trigger events in the "findById" method. He shows how to listen for a specific event (in his case, a "pre-execute" on the "findById" method) and a method for "short circuiting" the listener based on the response from the "trigger" call. He also touches on the "SharedEventManager" that can be used to add an event across all of your application at the same time.

Both the Module Manager and the MVC system use the Event Manger extensively in order to provide "hook points" for you to add your own code into the application flow. This is a list of the events triggered by each class during a standard request with the Skeleton Application.

It's broken up into the three main chunks - Module Manager, Bootstrap and Application - with any sub-requests and their sources (like "render", "dispatch" or "response"). You can find out more about ZF2's Event Manager in other posts like this one from Kevin Schroeder or this from Matthew Weier O'Phinney.

Basically, this allows us to have one piece of code to trigger an event and to have one or more listeners listening to this event. When the event gets triggered, the listeners are called and then we can do *something*, like caching or logging. Logging or caching. [...] See, that's my problem. All the event examples stop at logging and caching. Truly there must be some other example for which this event stuff can be used for.

In his example code, he's used the EventManager in one of his models to add listeners to validate the post and "slugify" the post's title for use on the URL. You can find his code on github if you're interested in the full implementation.

I got to play with the Event Manager. I did like the plugin functionality in ZF1, but it required some pretty static coding. In some cases, like the front controller plugins, it makes more sense (though this way seems more desirable). [...] It's a ZF1 application, but since (it seems) the event manager is self-contained (and the autoloader works with both ZF1 and ZF2) you can simply paste it into your include_path and BOOM, you have an event manager.

In his case he has a set of models extending a base class and wanted to introduce pre- and post-validation hooks to make it simpler to check the data he was working with. He includes the code for his base model class showing how he implemented the ZF2 EventManager in his ZF1 application. He attaches an event to the password class property and, on update, it automatically updates a temporary password value too.

You can get more information on using the EventManager in this other post from Matthew Weier O'Phinney.