Templates: Separating Business From Presentation Logic

Software design principles advocate that business or application logic should be separate from presentation logic. In the area of web development, this usually comes down to separating operations that act on user data and retrieve information to display to the user from HTML output. As an example, suppose we have a web application that searches many different hotel providers. The business logic for the search script might involve using XML interfaces to download the availability and rates of hotel rooms. The presentation logic would consist of the HTML page shown to the user.

The HTML page is usually put together from HTML snippets for areas such as the header, footer and navigation bars. Each of these snippets can be thought of as a template, and they will be grouped together in the search results template. The unique area of the page, the central part with the results, might be contained in the results template. This section must loop through the obtained results and display each one by one. However, the results won't have been obtained in the template, but in a script from which the template is called or displayed.

The template will have read access to certain variables made available from the calling script. As an example, in the results template a variable "title" might be made available for inclusion in the title tag. More complex variable types such as arrays and objects might be made available too. The results could be passed to the results template as an array of Result objects, for example.

More advanced template engines can also provide functions and modifiers for variables, as well conditional program flow constructs such as if/else statements. Such features attract criticism from people who think that the template "language" should have as few programming-like features as possible. Others think that so long as such features are used for presentation logic purposes only, they're fine.

Separating the presentation from business logic is good because changes to one can often be made independently of changes to the other. This means that designers can be given access to the templates and make changes in them without fear of breaking the complicated business logic. Similarly, programmers can focus on the logic without being surrounded by lines of HTML which have no direct relevance to what they're doing. However, the template designers and programmers still have to communicate about which variables will need to be supplied to the template.

Another benefit this separation brings is that it forces you to decide which logic belongs in the application layer and which belongs in the presentation layer. When these have been separated, you get a cleaner design with a more logical structure.

Where templates can sometimes be disadvantageous is in the extra layer they add to the processing of a web page. In many template systems, a template engine must first parse & process a template before delivering it as HTML output. Some template engines get round this by compiling templates to a script in the programming language. Some engines also provide caching options for templates.

Popular template engines include Smarty for PHP and Velocity for Java servlets. It is worth noting that you can use the PHP, JSP, ASP, etc., languages themselves for templates. The reason this is usually not done is because of the extra power the programming language provides (not necessarily a good thing from within a template being accessed by a designer) and because a template langauge will usually be a little bit more convenient for things like inserting variables into HTML, giving them default values and modifying them.

Books about template programming:
Smarty Php Template Programming And Applications
Mastering Apache Velocity (Java Open Source Library)