Zope Page Templates

In the early days of the Web, nearly everyone working on a web site was a programmer of some sort. You could be sure that every webmaster had installed his or her own web server, knew how to hand-code HTML and could write rudimentary CGI programs on their own.

Over time many editors, designers and other nonprogrammers became involved in the creation of web sites. Although it was often possible to teach these people HTML, it was HTML that was only good enough for static web pages.

Dynamically generated pages, which were then created almost exclusively by CGI programs, are another story altogether. After all, if the designer wants to change a site's background color on a static site, then he or she can simply modify the appropriate HTML files (or site-wide stylesheet, in today's world). But if such designs sit within a CGI program, the designer then must ask a programmer to make that change. This situation is bad for everyone; the designer cannot easily experiment with new ideas, the programmer is forced to make small and annoying changes and other programming work is put on hold while the programmer makes the changes.

For a number of years, the mainstream solution to this problem has been the use of templates, which mix HTML and a programming language. Perhaps the best-known commercial implementation of such templates is Microsoft's Active Server Pages (ASP), but Sun's JavaServer Pages (JSPs) is also quite popular. Open-source software developers have produced many high-quality template implementations of their own, including HTML::Mason (which works best with mod_perl), PHP (a programming language used for web templates) and ADP (available with AOLServer).

The idea behind such templates is quite simple: everything is assumed to be static HTML, except what is placed within a special set of brackets. When working with such templates, the designer is basically told, “You can modify everything that doesn't appear inside of <% and %>.” And indeed, this often can work well.

But over time, the drawbacks of such templates become increasingly apparent. For starters, what happens when you want to loop through a number of items that you have retrieved from a database, displaying each item in a different background color depending on its content? In such a case, you cannot ask the designer to ignore the code because the code and HTML are so intertwined.

Zope, the application server that we have been looking at the last few months, tried to solve this problem using something they call DTML (Dynamic Template Markup Language). As we saw several months ago, DTML is a programming language with an HTML-like syntax that allows developers and designers alike to create dynamic pages. DTML is powerful, flexible and easy to understand (at least if you're a programmer).

But if you're not a programmer, then even DTML can be difficult to understand, particularly when it is retrieving results from a database (as we saw last month). Moreover, HTML editors don't know what to do with the DTML tags, which can lead to the inadvertent mangling of DTML pages.

For all of these reasons, Zope Corporation (formerly Digital Creations), which develops the open-source Zope application server, is now encouraging developers to look at Zope Page Templates (ZPT), a new approach to templates meant to solve most of these problems. This month we examine ZPT, looking at ways in which we can use it to create dynamic sites.

ZPT takes advantage of three facts: HTML can be expressed in XML syntax, often known as XHTML; XML allows you to mix tags and attributes from different document definitions by using separate namespaces; and WYSIWYG HTML editors generally ignore (but preserve) attributes they do not recognize.

ZPT thus modifies the core HTML syntax by adding new attributes that sit in a separate namespace. Because these attributes are in a separate namespace, they are legal XML and XHTML. Because they are attributes and not tags, most HTML editors will ignore them, rendering the tag as if the attribute did not exist. And because web browsers ignore attributes that they do not understand, they can render ZPT pages without having to go through Zope.

In other words, ZPT makes it possible for a programmer to mock up a page so that a designer can then edit and view it using any tools they like. Of course, the dynamic elements of the template go into effect only when the template is viewed using Zope.

In HTML, each attribute has a name and a value, e.g., in <a href="http://www.lerner.co.il/">Reuven's site</a>, the attribute href had the following value: http://www.lerner.co.il/. The name and value are separated by an equal sign (=), and the value sits inside of double quotation marks. None of this changes when we work with ZPT, except that the attribute name is defined by TAL (Template Attribute Language). TAL defines a number of different possible attributes names, each of which directs Zope to modify the template in a different way when it is displayed.

TAL defines the attribute names, but what defines the attribute values? For that, we use TALES (TAL Expression Syntax). TALES defines a number of sources for data, including Python expressions and values from the surrounding Python namespace.

The combination of an attribute name from TAL (which tells Zope how to handle the surrounding tag) and an attribute value from TALES (which tells Zope what value to use in this TAL expression) gives us amazing flexibility in building page templates. In addition, the fact that TAL and TALES are published and have open-source specifications means that you can add to them if you have specific needs that they don't cover.