Comparison with PHP, ASP, JSP

Clearsilver Compared: vs. PHP, ASP, JSP

by David Jeske <david@neotonic.com>

There is one overriding goal of any HTML template system. That goal is to support the separation of the HTML presentation from your application logic. When systems do this properly, they are great templating systems. When systems do this poorly, they may be good Dynamic HTML programming systems, but they are not great template systems. This paper reviews different types of template systems to explain why dataset driven templates, like Clearsilver, offer the best combination of features for HTML templating.

Comparison Overview

Robust HTML Template systems can loosely be categorized into the following three styles: code in template, callback in template, and dataset driven template. Here is a breakdown of some template systems and which categories their common programming models fall into:

	Code in Template	Callback/Code in Template	Dataset driven Template
Custom Language	PHP, ColdFusion
Java		JSP	Velocity, WebMacro
Perl		Mason, Embperl, Apache::ASP	HTML::Template, Template Toolkit
Python		Cheetah, PSP	AHTS, htmltmpl, empy, cubictemp

Language Neutral n/a ASP Clearsilver, XML/XSLT

Systems to the left are faster to write one dynamic page in, and generally have a very quick learning curve for those new to HTML programming. Systems on the right are faster and easier for adding new pages to an existing site. Systems on the right are also more robust and flexible when writing, maintaining, and changing the look of many pages over time.

Code in Template

PHP is the best examples of a full code in template system. It is distinct from other systems because there is no separation between your code and your HTML templates. When you include your common library code, it is also sitting in Templates, all of which can output HTML. This offers the quickest route to writing a simple dynamic page. Programming can start with a static HTML mockup, and parts of the mockup can be incrementally replaced with programming logic, database lookups, and loops. If you simply need a system to quickly write a few dynamic pages, and you don't anticipate needing to change the look of the pages, this is the right kind of template system to use. This type of template system is ideal for applications such as small internal IT tools and small or free websites.

The drawback of using a code in template system, is that your code and HTML output quickly become forever intertwined. This makes changing the appearance of your pages difficult. For example, if you check the user cookie and load user database data in the "common-header" moving around where you include this template will change where you retrieve the database information for the user, possibly breaking other parts of the page which rely on that data.

It is possible with PHP or any other code in template system to choose to rigidly separate your application logic from your presentation code. To do this, all application logic is placed first in the template. This code merely fills in global variable strings which you use later to render the page and does not output any HTML. This method is successfully used in some PHP scripts, however, PHP does not especially help you do this, and as you'll see below, template systems designed to natively do this have additional features to make this type of programming easier.

Callback in Template

ASP (VB/C# embedded in HTML) and JSP (Java embedded in HTML) are both callback in template systems. This is because they encourage a two tier model where your application code is written separately and the template calls into your application code. This has the advantage that your application logic is largely separated into a separate place, and the page is mostly just triggering different actions and display actions to occur.

However, because these systems use a callback model, they have less than robust template rendering capabilities. Often ASP and JSP pages call into a callback to "render an html chunk". This happens most often because the looping functionality in these types of template system is not robust enough to easily iterate over a collection of items and access the sub-data of those items. This creates a hard to maintain mess of display logic which is split between your callbacks and your template, making it difficult to change the appearance of your pages without breaking their function. It also makes adjusting the presentation of pages accessible only to 'real programmers' who are very familiar with the code.

It is worth noting that PHP can be used as a callback in template system as well, by writing the bulk of the application logic in C (or separate PHP templates) and exporting those library functions to PHP. However, PHP is more often a combination of code-in-template and callback-in-template styles, not one or the other.

Dataset Driven Template

Dataset driven templates are a newer style of web programming which is gaining popularity. This type of template system is designed to enforce the separation of HTML presentation and application logic. Like callback in template systems, your application logic is separated into a separate library of code in your language of choice. Like code in template systems, robust looping and macro functionality are provided for building your appearance. In many ways these systems offer the best of both worlds, quick and easy webpage developement, and flexibility in changing your site appearance. Unlike either other style, there is no application logic in the template, only presentation code.

This separation is created by dividing page rendering into two distinct steps. In the first step your application logic runs and outputs its data into a static dataset. If you are familiar with command-line shells in UNIX and Windows, it will be easy to understand this by way of analogy. This static dataset is very much like the environment variables of your shell. They are a set of name/value relationships which are merely static strings. If your web application has the concept of a logged in user, then the dataset might contain the data "user=david".

In the second step your presentation template code runs. It only has access to this static dataset to do its job, and all work of read and writing to files or your database has already been completed. Using an approach where templates cannot do any real work assures that the order that HTML is output into the page is irrelevant. If you want the user information at the top, you simply reference that data at the top of your template, if you want it at the bottom, you reference it at the bottom.

This model offers many advantages over other template models. Here are a few of them:

Smaller application code - You can always put more data into the dataset than you need, and ignore it at the template level. This means that it is easy to make some generic "export" functions to push data into the dataset for your commonly used database elements or objects. You can selectively use whatever data in the template you like. Since loading an entire record from a database is generally the same speed as loading any part of a record from a database, this has little or no effect on performance.
Avoid partially rendered pages - One common problem with other types of template systems is that if an error occurs part way through the page, part of the HTML is already rendered and it is impossible to gracefully abort the page render. This results in a errors such as the PHP "error accessing the database" errors which get randomly stuck into HTML structure when errors occur. With dataset driven templates, all application logic has already run when it comes time to execute your template. If an error occurs, you can decide exactly what you would like presented to the user.
Performance analysis is possible - When using other types of template systems, it is impossible to get accurate data about how long your pages take to execute, because execution of your code is interleaved with sending data to the end-user. Using dataset driven templates, execution of application logic runs without blocking on data-output, allowing you to get accurate measures of your page execute performance. Futhermore, database transactions and other operations which occur while pages are rendering complete very quickly, instead of possibly dragging out while data is sent to a user on the other end of a slow link halfway around the world.
Performance optimization is easier - Because your templates are merely viewing a static dataset, it is irrelevant where that dataset comes from. If you need to reorder the way you fetch data into the dataset, your presentation templates remain unchanged. If you need to cache data and fetch it from a file or cookie instead of the database, again your templates remain unchanged.
Debugging is easier - Often when working with other template systems, bugs in your code will cause broken HTML. This output is very hard to sift through to discover the trouble. In dataset driven templates, you can always independently observe the output of the dataset itself. This allows you decouple the debugging of your application logic from your presentation template. Furthermore, broken application logic generally does not result in broken HTML, because the template logic still runs correctly against the data provided to it.

Conclusion

With these and many other advantages, dataset driven templates might just be the ideal way for you to simplify programming your web-based application by cleanly separating your application logic from your presentation templates.

Related Information

External Links

Choosing a Template System - a review of template system types for Perl
Rescuing XSLT - techniques for overcoming some of XSLT's overcomplexity
Dynamic Web Presentation with Java and XSLT - compares Webmacro and XSLT

What's New

Help Topics