(^262) CHAPTER 17 ■ THE ZEND FRAMEWORK APPLIED
Figure 17-1. The Zend Framework application flow
Creating Plug-ins
As you may have noticed, the framework has a number of events that are fired on a class known as
the PluginBroker, technically Zend_Controller_Plugin_Broker, which is a basic registration and
notification class. These events allow you an opportunity to interact and disrupt the dispatching
process. Typically, this disruption will be in the form of changing values in Zend_Request that will
have effects down the road.
For example, a forwarding plug-in could set the controller and action request parameters
at routeShutdown, and this would result in a totally different dispatch process. Another plug-in
might append or remove content from the response body at dispatchLoopShutdown.
Writing your own plug-ins is fairly simple. First, all plug-ins must subclass Zend_
Controller_Plugin_Abstract and may implement any of the PluginBroker methods shown in
Figure 17-1. With the exception of dispatchLoopShutdown, all methods are passed the current
Zend_Request object as their only parameter.
To get an idea of how this works, let’s look at a simple example. Create a class in your
library called YourPrefix_Controller_Plugin_Statistics, which will record each request’s
URI at routeStartup to a database. This plug-in is shown in Listing 17-4. This plug-in assumes
that you have a table called stats with a column called uri.McArthur_819-9.book Page 262 Friday, February 29, 2008 8:03 AM