PHPMaster.com has posted the second part of their series introducing you to one of the more popular design patterns in PHP frameworks right now - the Front Controller pattern. Part 1 introduced some of the fundamental concepts and this new article expands on that, getting more into the request and reponse handling process.

One of the best things about front controllers is that you can keep them running as tight structures, just routing and dispatching incoming requests, or you can let your wild side show and implement a full-fledged RESTful controller capable of parsing HTTP verbs, accommodating pre/post dispatch hooks, and the like, all behind a unified API. [I'd like to show] you how easy is to deploy a small, yet extensible, HTTP framework capable of putting to work a front controller along with the ones of a standalone router and a dispatcher. Plus, the whole request/response cycle will be independently handled by a couple of reusable classes, which naturally you'll be able to tweak at will.

He bases his examples off of the EPHPMVC project, showing how to implement a RequestInterface, ResponseInterface and link them together with a RouteInterface and use the DispatcherInterface to handle the requests. The front controller is then created with its run() method and an instance is created in a main PHP file that all requests are routed through.

In his latest post Matthew Weier O'Phinney introduces you to the new init() method in the Zend Framework 2 controllers and how it differs from the one in version 1.

In Zend Framework 1, controller's had an init() method, which was called after the controller was instantiated. The reason for it was to encourage developers not to override the constructor, and thus potentially break some of the functionality (as a number of objects were injected via the constructor). init() was useful for doing additional object initialization. [...] But this feature is missing from ZF2; how can we accomplish this sort of pattern?

In Zend Framework 2, there's no Controller constructor by default anymore, so you have to do things slightly differently. He shows you how to use the event manager to simulate the same thing, attaching an event to the "dispatch" of the controller to do the work. He came back and updated the post with a second method that could do the same thing - using the ServiceManager from inside a module and attaching the event that way.

Rob Allen has a new post to his blog today looking at bootstrapping specific modules in a Zend Framework 2-based application without having to do the entire set.

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.

In a new post to his blog today Matthew Weier O'Phinney takes a look at micro MVC frameworks and how, with just a bit of lightweight code and pieces of the Zend Framework, creating one is dead simple.

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.

In this new post to the Zend Developer Zone, they point out a workflow diagram Polley Wong has come up with showing how the Zend Framework's dispatch system works (request handling).

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.

New on his blog Jani Hartikainen has posted a simple idea that you can take to make sure you're getting the most out of your Ajax/Zend Framework connections.

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.

On the Zend Developer Zone, there's a new article that examines one of the key components to just about any framework out there - the front controller.

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.

On the SitePoint PHP Blog today, Troels Knak-Nielsen has written up a post concerning the current state of functional programming in PHP.

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.

phpaddiction has posted part three of its URL Rewriting tutorial series today - the creation of the "C" (Controller) in MVC.

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.

On the phpaddiction site today, there's part two of their tutorial looking at URL routing with PHP (started here in Part One).

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

There's code examples through out to illustrate each point as well as one main one at the end to show how to put it all into action. Their script reads in the URL and sends the command along to the CommandDispatcher - check out this example page to see it in action.