4. Implementing with PHP: Templates and the Web
AN OBJECT-ORIENTED PROGRAMMING PATTERN THAT PEOPLE often try to apply to Web programming is Model-View-Controller (MVC). MVC dictates that an application be separated into three components:
Model The internals of the system that perform all the core business logic. View The piece that handles formatting all output of the system. Controller The piece that processes input and communicates it to the model.
MVC originated as a SmallTalk paradigm for building agile desktop applications in which a given business process can have multiple methods of receiving data and returning output. Most Web systems receive data in only a single fashion (via some sort of HTTP request), and at any rate, the processing of all inputs is performed by PHP itself. This removes the need to worry about the controller component.
What remains after the controller is removed is the need to separate application logic from display logic. This provides a number of benefits:
Your application is more agile. A clean separation allows you to easily modify either the application logic or the outward appearance of your pages without affecting the other. Your code is cleaner. Because you are forced to decide what is application logic and what is display logic, your code often looks much cleaner. You can maximize display code reuse. PHP code reuse is common, but intermingling application code with your HTML makes it hard to reuse.
Implementing MVC in the Web environment is usually done via templates. In a template system, your HTML and display logic are held via a template. Your application code, which contains no display logic, parses the request, performs any needed work, and then hands raw data to the template so that the template can format it for display.
There are a wide array of template solutions for PHP. This chapter introduces Smarty, one of the most popular and flexible of the template solutions. It also shows how to implement an ad hoc template solution if you decide Smarty is not for you.
As a pure template language, Smarty is simple. But as you start implementing flow control, custom functions, and custom modifiers, the Smarty language can become quite complex. Any designer who can muddle through implementing complex logic in Smarty could do so in PHP. And that is not necessarily a bad thing. PHP itself is a fine template language, providing you the tools to easily integrate formatting and display logic into HTML.
If your environment consists of designers who are comfortable working in PHP and your entire team (designers and developers both) have the discipline necessary to keep business and display logic separate, then a formal template language may be unnecessary. Although I've personally never had problems with designers being unable to deal with PHP integrated into their HTML, peers of mine have suffered through integration headaches with design teams who could not handle PHP embedded in their pages and have had great success with using Smarty to address their organizational problems. Even if your design team is comfortable with PHP, template solutions are nice because they try to force the separation of display from application control.
Besides creating a formal separation between display and business logic, the best justification for using a template solution such as Smarty is to give untrusted end users the ability to write dynamic pages, without having to trust them with access to PHP. This situation can arise in offering virtual storefronts, offering customizable personal pages, or offering template solutions for crafting emails.
| 