Building a PHP Front Controller

by Q Ethan McCallum
07/08/2004 I recently had the opportunity to implement some small (noncommercial) web sites in PHP. One of many decisions I faced concerned the templating strategy: duplicated, include()-based template pages weren't quite future-proof, while a formal, external template library would have been overkill.

Luckily, the web host in question permitted certain key Apache directives in .htaccess that let me customize request handling. Add to that PHP's OO support and my templating decision reached a comfortable middle ground in the form of a custom Front Controller.
The Front Controller design pattern describes a way to centralize processing in a web-based application. Routing all requests through a single entry point provides a place to apply common application logic, and, at the same time, reduce dependencies between other components. All of this adds up to a site that is easier to maintain and extend.
In this article, I will share a stripped-down version of the controller I implemented to mediate the relationship between content and layout.
What I explain here is not limited to PHP; the Front Controller design pattern is available in many server-based dynamic web design toolkits, such as mod_perl and Java servlets/JSP. Unlike those technologies, this article's implementation of the Front Controller requires only a modest Apache setup. Your PHP web host most likely supports the required configuration.

Related Reading PHP Cookbook By David Sklar, Adam Trachtenberg

The sample code was tested under Apache 1.3.27 and PHP 4.3.4.

First, Some Theory

A web server is typically a glorified file service. A client asks for a file and the server retrieves it. The Uniform Resource Identifier (URI) specifies a file under the document root, so the request and response are closely related.
Web servers may also invoke executables, such as a CGI or PHP scripts, instead of fetching raw files. Executables insert logic between the request and response, changing portions of the latter (to add a customized greeting or pull different records from a database, for example) with each call.
It's possible to route all requests through a single executable, generating an entirely different page for each one. In this case the executable is the site's Front Controller and the generated response is the view. The URI and request parameters comprise a command issued to the controller, which performs some logic to decide which view to return to the client.
The controller's central location in the request-response cycle makes it a suitable place to apply common logic for checking credentials or setting response headers.
A controller-managed web site operates independently of the underlying web server to a certain extent; file access, authentication, and content generation take place within the code. This is why the controller can access files from directories that otherwise have .htaccess restrictions.
Purists will note that the description here is abbreviated, with some participants, such as the dispatcher, folded into the main controller. The code is a starting point which you may extend as needed.