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.

If you've done any work with PHP frameworks, the concept of a "front controller" should be a familiar one. If you haven't, the idea might be new to you and PHPMaster.com has started off a series that will introduce you to the basics of the Front Controller design pattern in a few different parts.

Some are now grumbling about newer concepts that have recently made inroads in day-to-day PHP development, saying Front Controllers are a redundant “reinvention of the wheel” which should be discarded ipso facto. [...] In this two-part article I’ll be exploring in depth a couple of straightforward approaches that you might find appealing, especially if you’re trying to implement an expandable front controller from scratch without sweating excessively during the process or having to cope with the burdens of a bloated framework.

This first part of the series introduces you to some of the basic concepts of routing and URL handling and shares the code for a basic front controller. It parses the URL and sets up the controller and action to hand the request off to. Also included is the contents for the .htaccess file you'll need to include to route all requests back through this controller instance.

Rob Allen has another Zend Framework-themed post to his blog today looking at handling exceptions in front controllers a bit more correctly than they're currently treated.

If you have a Zend Framework Front Controller plugin which throws an exception, then the action is still executed and then the error action is then called, so that the displayed output shows two actions rendered, with two layouts also rendered. This is almost certainly not what you want or what you expected.

He points out the more correct process it should follow - dispatch the request and catch the error there before the request continues. The error is then tossed to the error controller for correct handling. He includes the code to do just that, showing how to wrap the routing in a try/catch and push the exception over to the error controller with an "error_handler" plugin created with an exception type of "other".

As a part of his demo (presented at a local user group meeting) Bradley Holt, not having enough time to squeeze in all of the content he wanted, has started off a series of posts to his blog about the Zend Framework and the specific areas that make it up. His first article is about the front controller.

Like many other frameworks, Zend Framework provides an implementation of the Front Controller pattern. This means that all HTTP requests can be sent through a centralized point. This allows you to take advantage of Zend Framework's routing and Model-View-Controller (MVC) components, if you so choose.

He talks about where the Zend Framework places this controller and what their version of it contains - constant definitions, loading paths and the creation of a Zend_Application instance that's called to do the real work. He also includes a few helpful tips on common problems you might come across when setting up your application.

On the PHP in Action blog this new post talks about something that's at the core of the front controller for most frameworks - a call to a user function based on the passed in action.

The core of your average web framework is a Front Controller. Front Controllers are commonly considered complex and esoteric. That's a myth. I sometimes brag that I can construct a Front Controller in 15 minutes. Actually, it's doesn't take quite that long. In PHP, a Front Controller can be simplified to just one line of code.

This one line of code, while a very dangerous thing to actually use in an application, illustrates what a front controller does to forward out the request to the rest of the framework. He revises it with a Zend Framework-ish example that splits the request out into a controller/action method.

The phpaddiction website has posted the first part of a series today covering URL routing with PHP (commonly used by frameworks to route requests through a centralized location.

Most PHP frameworks use some variation of the front controller pattern to centralize common code and logic. There are advantages and disadvantages to this. I am going to ignore those for now. In fact the first part of this series will explore a simple procedural URL routing method that contains many of the disadvantages. In later articles we will build upon this basis and address the disadvantages.

He walks through the steps to get things set up - working with mod_rewrite, creating the "entry point" for your application, and finally, how to execute a command based on the request's action.

The phpaddiction website has posted the first part of a series today covering URL routing with PHP (commonly used by frameworks to route requests through a centralized location.

Most PHP frameworks use some variation of the front controller pattern to centralize common code and logic. There are advantages and disadvantages to this. I am going to ignore those for now. In fact the first part of this series will explore a simple procedural URL routing method that contains many of the disadvantages. In later articles we will build upon this basis and address the disadvantages.

He walks through the steps to get things set up - working with mod_rewrite, creating the "entry point" for your application, and finally, how to execute a command based on the request's action.