Home ›

Zope Page Templates

Issue 98

From Issue #98
June 2002

Jun 01, 2002  By Reuven M. Lerner
 in
Discover how ZPT attributes can work with HTML to create useful and compatible dynamic web sites.
Some Simple Examples

Now that we've discussed the theory behind ZPT, let's look at some examples. The first example is the skeleton document that Zope creates when we start a new page template. To do this, go to the /manage URL on your Zope server, and choose page template from the Add product list in the upper right-hand corner. (If you don't see page template on the menu, it could be that ZPT is not an installed product. You may have to upgrade your copy of Zope to a more modern version in order to use ZPT.) As is usual in the Zope world, you will then be asked to enter an ID (i.e., a unique character string that will appear in the URL) for this new product. Enter a short name and click “Add and edit”.

When you follow these instructions for a DTML document or method, you are brought to an editing screen that contains skeleton DTML. The same is true for a page template, except that the skeleton document obviously contains TAL and TALES expressions:

<html>
  <head>
     <title tal:content="template/title">
      The title</title>
  </head>
  <body>
     <h2><span tal:replace="here/title_or_id">
          content title or id</span>
         <span tal:condition="template/title"
               tal:replace="template/title">
               optional template id</span></h2>
     This is Page Template
     <em tal:content="template/id">template id</em>.
  </body>
</html>

This document might be short, but it effectively displays TAL and TALES and how they might be used in actual documents. Here are the TAL attributes that this skeleton uses:

  • The tal:content attribute replaces the contents of the tag with the value of the TALES expression. So in this example document, the words “The title” will be replaced by the value of the TALES expression template/title, which we will discuss below. The <title> and </title> tags, along with their attributes, are left alone, but the text between these tags is changed when the template is presented by Zope.

  • The tal:replace attribute is similar to tal:content, except that it replaces the content and the surrounding tags. This is frequently used with the <span> tag, which is largely used as a placeholder for such markup in any event. Thus everything from the first <span> tag to the first </span> tag, including the tags themselves, will be replaced by the value of the TALES expression here/title_or_id.

  • The tal:condition attribute only displays its contents if its value is a true value, which is anything other than 0, the empty string, an empty list or the built-in ZPT “nothing” variable.

You might notice that the second <span> tag contains two TAL attributes, tal:condition and tal:replace. When Zope encounters multiple TAL attributes in a given tag, it first evaluates definitions, then conditions, then repeat loops, then content and replace tags. (You cannot have both content and replace attributes in the same tag, because they are mutually exclusive.) In the second <span> tag, Zope inserts the optional template ID only if the template/title TALES expression is true.

In addition to content, replace and condition, TAL defines three other attributes:

  • tal:repeat allows us to loop over a list of items. If your template will display a list of search results, rows from a database or files in a folder, then you can loop over the contents and display the contents in a variety of ways.

  • tal:attributes allows us to replace (or add to) an attribute of the enclosing tag. For example, we can set the href attribute of an anchor (<a>) tag at runtime by adding a tal:attributes attribute in that <a> tag. The value of the TALES expression will be used to set that attribute when it is evaluated at runtime.

  • tal:define allows you to set a new variable, which is then accessible from within enclosed tags. This variable value can be passed either along to other TAL tags or displayed.

TALES

Now that we have covered TAL, let's look at the TALES expressions that we can assign to a TAL attribute.

The simplest sort of TALES expression is a “path expression”, which describes a Zope object relative to the template, its container or the request. Path expressions are similar to URLs, except that they begin with a name rather than the root object /. The final element of the path expression typically will be a property that can be displayed (using tal:content), tested (using tal:condition) or iterated over (using tal:repeat).

The ZPT skeleton document uses four TALES path expressions:

  • here/title_or_id, which returns the value of the optional “title” property (if it exists) or the mandatory “id” property (if there is no title) to a tal:replace attribute.

  • template/title, which returns the (optional) title of the current template to tal:condition followed by tal:replace.

  • template/id, which returns the “id” property of the current template.

A TALES path expression that begins with “template” refers to the template object itself, while one that begins with “here” refers to the object to which the template is being applied—it may be the template itself or another object entirely. Some other relative markers are “request” (the Zope HTTP request object), “repeat” (information about current tal:repeat loops), “options” (for the parameters passed to the template) and “container” (for the folder of the current object).

TALES path expressions are great but are not as flexible as we might sometimes need. TALES thus allows you to return Python code by beginning your TALES expression with “python:”. For example, we can include the result of a simple calculation in a template with the following code:

<p>2 + 2 = <span tal:replace="python:2+2">
            number</span></p>

There is also a “string:” TALES prefix that indicates that the value should be treated as a text string. String expressions may contain interpolated variable values by prefixing the variable name with $, as in Perl and shell scripts. You may optionally surround the variable name with curly braces ({ and }), as in ${x}.

______________________

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions