Common features
The goal of Page Templates is to allow designers and programmers to work together easily. A designer can use a WYSIWYG HTML editor to create a template, then a programmer can edit it to make it part of an application. If required, the designer can load the template back into his editor and make further changes to its structure and appearance. By taking reasonable steps to preserve the changes made by the programmer, the designer will not disrupt the application.
Page Templates aim at this goal by adopting three principles:
- Play nicely with editing tools.
- What you see is very similar to what you get.
- Keep code out of templates, except for structural logic.
A Page Template is like a model of the pages that it will generate. In particular, it is parseable by most HTML tools.
To the HTML designer using a WYSIWYG tool, the dynamic headline example is perfectly parseable HTML, and shows up in their editor looking like a headline should look like. In other words, Page Templates play nicely with editing tools.
This example also demonstrates the principle that “What you see is very similar to what you get”. When you view the template in an editor, the headline text will act as a placeholder for the dynamic headline text. The template provides an example of how generated documents will look.
There are template statements for replacing entire tags, their contents, or just some of their attributes. You can repeat a tag several times or omit it entirely. You can join parts of several templates together, and specify simple error handling. All of these capabilities are used to generate document structures. Despite these capabilities, you can’t create subroutines or classes, perform complex flow control, or easily express complex algorithms using a Page Template. For these tasks, you should use Scripts or application components.
The Page Template language is deliberately not as powerful and general-purpose as it could be. Other objects handle business logic and tasks unrelated to page layout. For instance, template language would be useful for rendering an invoice page, generating one row for each line item, and inserting the description, quantity, price, and so on into the text for each row. It would not be used to create the invoice record in a database or to interact with a credit card processing facility.
Note: extracted from The Zope Book.
Differences
Because ZPT-JS isn't running in the context of Zope and isn't written with Python, there are necessarily some important differences between ZPT-JS and ZPT. Some of them are:
Topic | ZPT-JS | ZPT |
---|---|---|
Side | Client and server side (using Node.js) | Only server side |
Variable declaration | Yes, using data-declare statement | No |
Strict mode (*) | Yes, using data-declare statement | No |
Script language | Javascript | Python |
I18n and L10n support | Yes, but attributes differ | Yes |
Nocall support | Yes, it is a suffix in data-define | Yes, it is an expression |
Map support in data-attributes | Yes | No, only key/value pairs are supported |
Support of expressions in data-use-macro and data-fill-slot | Yes | No, only string literals are supported |
Template code is valid HTML code (w3c compliant) | Yes, using the default configuration | No |
Last release | 25 April 2019 | ? |
License | LGPL 3 | Zope Public License |