- More DTML Options: Process Flow Control
- DTML Expressions
- About This Article
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
DTML Expressions
The most important DTML concept to get your hands around the right away is the difference between a name and an expression. The simplest way to refer to a Zope object is by name. The example in Listing 3 includes several instances in which an object is simply referred to by name and the syntax is crystal clear—for example, look at line 07: <dtml-if page_body>.
As mentioned earlier, this <''dtml-if> tag asks a question, "Is there a variable, at this time, with the name page_body?" However, the simplicity is misleading because this is actually a shorthand version, which is allowed for ease of use. The complete syntax is <dtml-if name="page_body">.
This syntax is still pretty clear and not too difficult. Now look at the next line, the second <''dtml-if>, on line 08:
<dtml-if "page_body[-4:]=='.stx'">
Like we said, a bit of explanation is in order.
From Names to Expressions
The previous line of DTML asks a much more complicated question, with specific details about character order and placement within a text string. This sort of question cannot be expressed by referring to the name of an object. It is an example of an "expression," a programming term for a construct that must be interpreted to be understood. If you call out someone's name and that person hears you, she will probably respond, and you've accomplished your goal. If you have to go about inquiring after an individual by description, things get more complicated. That's why the expression is contained in double quotes. They tell ZPublisher, "This is complex, so put on your interpreting hat."
You've already looked at the "slice" syntax. So, move on to the == part. This is the equality comparison operator. There are two equals signs to distinguish this from the action of assigning a value to a variable. For that, you use a single =, which is the variable assignment operator. The comparison to be made in this case is to determine whether the value stored in the page_body variable is an exact match in its last four characters for the character string ".stx".
So, you've seen that DTML expressions must always be enclosed in double quotes. Fortunately, single quotes are just as effective for designating character strings, or this would have been even more confusing. The single quoted string is "nested" within the double-quoted expression to eliminate confusion about where each type of quotation starts and ends. Look around for other instances of single quotes within double quotes. Whenever you see this configuration, it is a case of a character string "nested" within an expression.
Things get even more complicated when you realize that in the example shown in Listing 3, the value stored in the variable, page_body, is just a text string, which happens to be the name of another object. That's why you are able to compare the last four characters to another string (".stx"). However, when you want to insert the object that the page_body variable refers to, you don't want to have that object's name accidentally appear on the web page where you expected to see the object that the name "means." After all, having your name on a place marker at a meeting isn't quite the same as actually being there yourself. To avoid rendering an object's name on a web page when you want to display the object itself, you need a way to express an object with a name that is the same as the string stored in this object. That's where the _[page_body] bit comes in.
The special variable _ indicates that ZPublisher should search the current "name space" for whatever is between the brackets. You have likely guessed that _ is called the name space variable. The item between the brackets is a variable, page_body. When a variable is presented this way, as _[variable_name], ZPublisher "knows" that it must look for an object with the name that is stored in that variable. It is a subtle point, but once you have this clear in your mind, many details become considerably easier to grasp.
Now, what is a "name space"? Think of the name space as the collection of all the names of all the objects that are available at the present moment. The <dtml-let> tag is a good example of the importance of the "present moment" part. From the start of the <dtml-let> to its close, any variables assigned by it are available in the name space. Afterward, those variables are gone and can't be found. Searching for them after they cease to exist in the name space will result in an "empty" value (false), which will generate an error.
As you are no doubt coming to realize, there is much more to this than can be covered in a paragraph. Still, a basic understanding will serve for the majority of cases. For a precise explanation of the name space, see http://www.zope.org/Members/michel/HowTos/NameSpaceHow-To.
Zope's talent for finding objects is also seen in the concept of acquisition. There is a web "slide show" on that topic at http://www.zope.org/Members/jim/Info/IPC8/AcquisitionAlgebra/index.html.
How to Use DTML and When Not To
The previous listings are adequate to demonstrate that DTML is potentially a very powerful programming tool. Now that you know that, try not to use it that way. You've seen enough in this brief exposition to realize that it can only get more difficult to understand as the tasks that you need to accomplish become more complex. DTML is a fine tool for building page templates with wonderful features for meeting your web presentation needs. Understanding that DTML was never meant to serve as a complete programming tool is the most important part of learning when to use DTML and when to reach for another tool.