Castwide Developer's Resource

The Template Debate

Template engines are a controversial subject in the PHP community. Besides the debate over which engine to use, many developers believe that template engines are not necessary at all. Developers in favor of templating systems use them to establish a clear separation of presentation logic from application logic. Opponents argue that PHP itself can be used for templates without adding the overhead of a separate parser and the complexity of a new language.

Both sides have good points. I prefer to use a templating system in my own applications, but I also think that most systems take a flawed approach. In this article we'll look at some of the arguments on both sides of the debate. Then I'll explain my reasons for using a templating system, including my opinions of what makes a good one.

Reasons for Templating Systems

Templating grew from a need to implement MVC and similar design patterns that assist manageability. These arguments explain the reasoning in more detail.

Using a template engine enforces separation of presentation from application code. This is often an important goal in large projects. Designers should be able to write templates without worrying about database connections, SQL queries, input scrubbing, session handling, and all the other details that belong at the application level.

A templating language is easier to learn than a programming language. Giving designers a smaller, simpler interface to the application allows for less of a learning curve and a faster development cycle.

Templates are more portable and easier to reuse. A strong separation will not only reduce the amount of programming that designers need to do, it will also allow progammers to make drastic changes to the application without affecting the templates. With a robust enough template system, it should be possible to modify business logic or move to a different RDBMS without needing to change the templates. It might even be possible to use the same templates in conjunction with a different programming language.

Reasons against Templating Systems

These are some of the more common arguments I've seen against template engines.

Template engines add complexity. They add another potential point of failure. They require programmers to learn a new language. They require designers to understand how their templates receive data.

Template engines hurt performance. The overhead involved in parsing templates makes them undesirable in the enterprise, or any application that needs to handle high traffic.

PHP is already a templating language. The syntaxes used in template engines are often similar to PHP, but they provide a smaller subset of functionality. Commonly replicated features include control structures like for, if, and switch. This sandbox approach can keep designers from polluting scripts with application logic, but if the templating language looks like a programming language, the argument about simplicity goes out the window. {section name=foo loop=$bar} is not significantly easier to use than <? foreach ($foo as $bar) ?>. Instead of obfuscating the issue with a new language, designers can use PHP itself to work with data provided by the application code.

What Makes a Good Templating System

The strongest point against template engines is that PHP is already a templating language. The mistake that many templating systems make is to use a language similar to PHP. If the templating language is not significantly easier to use than PHP, why bother?

This problem lies not so much with the concept of templating systems as with the design of many templating languages. Here are my guidelines for a proper templating language.

Templates should not be used for application logic. If your templates contain database connection strings and SQL queries, they're doing the application's work. The purpose of a template is to receive data from the application. The only logic it performs should be presentational, e.g., it can determine whether to display a table of data or a message explaining that no data is available.

A templating language should be a markup language, not a programming language. An XML-based language works best. There are two major advantages to this approach. First, web developers should already be familiar with XML syntax. Second, XML is easier to manage in text editors, WYSIWYG designers, and other software.

Advantages of a Good Templating System

There are several benefits to a templating system that uses an XML-based markup language.

Ease of support. HTML editors can make better use of XML-based templates than scripts. For example, it was trivial to customize Dreamweaver to handle the PHP Pagemill's syntax and to provide a property inspector for the smart select tag.

Separation of presentation logic from application logic. Enforcing this separation is an important goal of MVC frameworks.

Orthogonality. The better separated the components of a web application, the easier it is to change one of them without breaking the others.

Portability. XML-based templates are easier to use in other applications, even (or especially) applications written in different languages. They are also easier to convert.

Simplicity. Designers and developers alike should find it easy to understand the templating language's syntax because they are already familiar with XML through HTML.

In conclusion, my opinion is that template engines themselves are not the problem. Poorly designed ones are.

Related Links

• A Tale of 3 Templates: Members of the NY PHP Community compare three templating solutions, plus the pure PHP approach.
• Why Use Smarty? The official Smarty web site discusses reasons to use a templating system.
• PHP Architect Podcast, August 16, 2007: PHP Architect discuss the Blitz templating system and template engines in general. Of particular note is Sean Coates's comment on the page regarding his dislike of an interpreted layer on top of PHP, although they use XML->XSL->HTML transformations internally; which, in my opinion, is an excellent approach.
• PHP Pagemill: Castwide's open source template engine, which powers the Phrameworks CMS.

More News