I recently had a problem with a ZF2 based website where users were reporting seeing the error page displayed, but I couldn't reproduce in testing. To find this problem I decided to log every exception to a file so I could then go back and work out what was happening. In a standard ZF2 application, the easiest way to do this is to add a listener to the 'dispatch.error' event and log using ZendLog.

He uses an event listener to attach a service that contains a "logException" method. This method uses the ZendLog component to write out the error message to a local log file including a backtrace of where the issue occurred.

As more frameworks and libraries, particularly in the PHP world, move towards adopting the Dependency Injection pattern they are all faced with the problem of bootstrapping their application and constructing the object graph. In many cases this is solved by a Dependency Injection Container (DIC). Such a container manages the creation of all the things. The things it manages are services. Or are they?

He notes that, according to some of the principles of domain-driven design, "services" should be stateless - the results of calls to the service shouldn't alter it, it should only depend on the values passed in. He goes on to put this into the context of a DIC and gives an example of the "request service" (and how it violates the DDD principles of statelessness). He talks some about scopes (dependencies) and mutable services. He talks about methods to get around these issues with the "request" instance, ultimately coming to the conclusion that event listeners might be the way to go.

Traditionally, application components have been designed to operate on and control the execution environment, an approach that delivers well to some extent. [...] Instead of making the module completely responsible for logging data to multiple endpoints, we can transfer the responsibility straight to the external environment. [...] Not surprisingly, the process of inverting these responsibilities between components and the environment is formally known as Inversion of Control (or in a more relaxed jargon, The Hollywood Principle), and its implementation can be a real boost when it comes to developing extensible, highly-decoupled program modules.

He uses a set of domain objects (Posts and Comments in a typical blog structure) and the Observer pattern to show how mixed up things might get if the application isn't carefully coded. He takes this and updates it to include a "comment notification service" that implements the SplObserver and is attached to the post to be executed on an event (in this case, the setting of a new comment).

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.

In previous Zend Framework apps I've written, I often handled access control at the level of the controller action. Each action was represented in the ACL as a resource, and the ACL logic was applied by a custom plugin just prior to any action dispatch. [...] As a result of these concerns, I decided on a lower-level, model-centric approach for this blog: my models are my resources. Each model class implements Zend_Acl_Resource_Interface, and the ACL specifies "create," "read," "update" and "destroy" privileges for each class (more or less).

Checking for the permissions with a setup like this can be time consuming, though, so he found an ally in the record listeners Doctrine allows you to set. He combines a Doctrine_Record_Listener object with a Zend_Acl one in a preInsert method with a getCurrentRole to add the user handling all in one place.

When testing code which uses the database, you would usually want to make sure the database stays pristine for each test - All tables should be empty, as any extra data could interfere with the tests. You could probably write an extended Testcase class which automatically does this before each test in setUp and afterwards in tearDown, but it may have some issues. [...] Luckily, PHPUnit has a way to add event listener that react to certain events.

It uses the TestListener interface to make the event handler that (with the help of Doctrine) starts up, makes the tables with data and wipes them out at the end.

Code for the sample listener is in the post and included is the method for checking to see if you even need to use the database or not.

The latest webdevradio podcast is up. One of the topics is a question for listeners about PHP learning resources; specifically, what are some good resources to learn PHP OO? I also ask about what listeners would recommend to someone just getting in to the webdev field these days - .net, java, ruby, php, something else?

You can either subscribe to their feed to get this (and future episodes) or just get the mp3 only. He also has a web player on the post to listen there as well.