Principles and Problems

If you have worked for any length of time with PHP, you are bound to have encountered the problem of structuring larger projects. Because embedding PHP in HTML code is easy, the temptation is often to mix the logic of your application with its presentation.

This soon causes a number of problems, however. You tend to find that you are copying and pasting code between files, as the views in your project increase. When you add to your code, you suddenly find that you must repeat your amendments across many pages. Some parts of your project might rapidly fall out of synchronization with others, especially if you are working as part of a team.

Another problem of binding your logic and presentation is the difficulty for designers. You might be a master of all trades, but on larger projects team members typically specialize. Designers want to concentrate on designing without negotiating too many forests of control structures and thickets of quotation marks.

Most PHP programmers define a central set of code libraries and application functions and minimize the amount of code that lives within the PHP pages themselves. The question remains, though, as to how a request flows. Should it flow from the PHP presentation, up to a bank of functions? Many environments work in this way. The trouble with this approach lies in duplication. Even if every PHP page delegates responsibility for handling the client's request to a library function, you must still reproduce this delegation (the function call) and embed it in every page.

Many developers are now deploying an alternative structure, which is commonly used in object-oriented languages such as Java. The so-called MVC (model-view-controller) pattern splits an application into tiers. The controller tier is responsible for managing the messaging of an application. In a Web context, it handles an incoming request, delegates objects to act on the request, and then delegates a view to present the response to the user. So, a request always is routed to the same place—a controller object—and views vary according the nature of the request and of the success of the script in responding to it.

To keep the structure flexible, you don't want the controller to be all-knowing about your application. If you had to program in every action the system might need to take and every page the system will present, the controller object would quickly become hard to manage. So, the MVC pattern presents some challenges. How do we interpret a request and select an action? How do we use this flexibly, so that our code can be reused in different projects, and so we can add new actions to our project with the minimum of difficulty?

Another challenge lies in dispatch. After the system has responded to a request, our controller needs to delegate to the view tier. Somehow we need to map the actions the system takes, and the success (or otherwise) of those actions, to views.

In this chapter, we concentrate on the challenges of the controller and view parts of the MVC pattern and address these problems of command and dispatch. We will write some library code to demonstrate potential solutions, as well as some toy code to illustrate our framework in action.

Along the way, we will take in a lot of PHP's new, advanced object-oriented features.