Following on from the discussion on modules, we can hook into the event system to do module specific bootstrapping. By this, I mean, if you have some code that you want to run only if the action to be called is within this module, you can hook into the Application's dispatch event to achieve this.

He starts with an example of a basic module (Simple/Module.php) and shows how to define an "onBootstrap" method that calls the "onDispatch" method (when hooked to the event manager) to do some module-specific bootstrap operations. The RouteMatch feature is used to ensure that you're in the right controller/namespace combo to use the module.

My job is great: I get to play with technology and code most days. My job is also hard: how does one balance both functionality and usability in programming interfaces? [...] One interface I've been toying with is inspired by two very different sources. The first is PHP's own SoapServer API (which we use already in our various server components); the other was a discussion I had with Fabien Potencier (of Symfony fame) a couple years ago, where he said the goal of Symfony 2 would be "to transform a request into a response."

The result is a simple Dispatachable interface that acts as the lowest level to build the whole MVC on top of. He illustrates with a micro MVC example that uses the Dispatchable interface to create a Dispatcher class to handle the incoming requests and attach various endpoints for handling. An example of it in use is also included.

I've been researching Zend Framework lately and was curious about what's actually happening behind the scene of the whole dispatch process. Inspired by Thorsten Ruf's (zenddispatch_en.pdf) clear and beautifully presented workflow, I decided to go a step deeper and crawl Zend Framework's code. I came up with my own version of the flexible yet complicated workflow.

You can check out this new PDF here. It diagrams out an overall view of the request handling, a look at what happens inside the front controller including components like the Controller Dispatcher, Action Controller, Action Helper Broker and Response Object.

A common reason to use Ajax in a website is to make it feel faster, so you usually want Ajax requests be processed as quickly as possible. While there are many ways to speed up Zend Framework based applications, there are still some things like routing and dispatching which still add up to the total. There is, however, another way to make Ajax work even faster

Since Ajax requests don't usually require all of the complex routing and dispatching that a normal Zend Framework request might, he recommends creating a separate Ajax handler. His includes an example of a simple searching endpoint with a class handling the backend logic. A simple handler script loads up the bootstrap and makes the request for the search, returning the search results in a JSON format.

Like Action Helpers, which I've discussed in a previous article, Front Controller Plugins in Zend Framework are often considered an esoteric, advanced subject. They are, however, remarkably simple to implement, and provide an easy way to extend the functionality and behavior of your entire web application.

The article (from Matthew Weir O'Phinney) looks at the hooks defined in the controller, like routeStartup and preDispatch, and how to work with the controller to add in/get plugins from it. He provides a two examples too: Application Initialization Plugin and a Caching Plugin.

With the rise of Javascript, and languages like Python and Ruby, functional programming is becoming more mainstream. Even Java seems to be getting closures in the next version, so does this leave PHP lacking behind or is there an unrealized potential hidden within?

He looks at a few different aspects of functional programming and sees how well PHP fits into them (like dynamic dispatch, binding a variable to a function and an implementation of currying for a function). This last option is the only "true" functional feature that PHP can realistically handle.

In the final part of this series, I will build a functional modular front controller that can be easily adapted to small projects. It is basically the "C" in MVC for a simple MVC framework. If you haven't read the first two articles I recommend that you read over them first. Url Routing with PHP - Part One and Url Routing with PHP - Part Two.

They start with the base created before (with some slight modifications) and build up the dispatcher to handle their new requests and the controller to respond. In their example, when the Controller is called, it runs the execute() method and, based on the input, either calls another function or returns an error if it doesn't exist.

With the foundation of the routing in place (from part one), they move on to bigger and better things:

• assign responsibilities (what needs to be accomplished)
• creating a standard command object
• interpreting the URLs and the parameters passed in it
• using this information to dispatch the correct commands

Zend Framework 0.6.0 release comes with improvements in Zend_Controller area (new Zend_Controller_Request, Zend_Controller_Response classes, dispatch process improvements), which looks very promising. Dispatching process now better described and its parts (Zend_Controller_Router and Zend_Controller_Dispatcher) are replaceable.

He also includes a diagram of how it's all laid out and a brief description of how each of these new pieces works.

Zend_Controller_Plugin is not covered yet in the documentation but it is a powerful way of extending a controller. Briefly, Zend_Controller_Plugin is used for extending controller functionality by attaching listeners to events, which are fired (or trigged) by the controller classes.

He talks about the plugin interface, how it hooks into the controller and defines the relationship with some pseudo-code (showing implements versus extends). There's talk of the Zend_Controller_Plugin_Broker class and the Zend_Controller_Front. He looks in detail at this last class, showing how it helps to handle incoming requests for the plugin functionality and veen includes working code you demonstrate how.