Building a Complete Website using the Template Toolkit - Benefits of Modularity (
Page 3 of 15 )
Separating commonly used blocks of markup into reusable template component files in this way allows you to take a modular approach to building your web content. This brings a number of important benefits.
The first is that the page templates become easier to write, edit, and maintain. You can quickly and easily add new pages by reusing existing template components to do the repetitive work, leaving the template author to concentrate on adding the core content. When it comes to updating the content, it becomes a lot easier to find what you’re looking for because you don’t have to pore through great chunks of HTML markup that define header, footers, menus, and other user interface elements.
In other words, we’re achieving a clear separation of concerns between the core content of the pages and the parts that deal mainly with presentation. Content authors can concentrate on writing content without worrying about what kind of fancy user interface the web designers have dreamt up to fit around it
The second benefit is that the headers, footers, and other template components can easily be updated at any time, and need to be modified only in one place. Changing the copyright messages, the background color, or perhaps the layout of the footer, for every page on the site, becomes as easy as editing the one template component file and then processing the page templates to rebuild the site content.
So the clear separation of concerns also works the other way around. Web designers can concentrate on building a nice user interface for the entire site without having to worry too much about the content of individual pages.
Even if you’re the all-in-one web designer, content author, and webmaster for your site, it is still useful to maintain a clear separation between these different aspects. You may have many hats to wear, but you’ll be most comfortable wearing just one at a time.
Defining Variables
Our current use of tpage for processing templates is hardly streamlined. We’re spending a lot of time typing variable values on the command line, something that can only get worse as we add more pages that require processing to the site.
It would be easy to mistype the value for a variable, for example, or perhaps supply the wrong value altogether. You wouldn’t see any complaint from the Template Toolkit. It would just go right ahead and process the template with whatever values you supplied, possibly leading to an error on an HTML page that could go unnoticed.
Confguration Template
A better approach is to create a template component that defines any commonly used variables in one place. Example 2-7 shows our config template.
Example 2-7. config
[% author = 'Arthur Dent'
bgcol = '#FF6600' # orange
year = 2003
copyr = "Copyright $year $author"
-%]
You can define any number of variables in a single directive, as Example 2-7 illustrates. The Template Toolkit is very flexible in terms of the syntax it supports inside its tags, allowing you to spread your directives over several lines, adding as little or as much whitespace as you like for formatting purposes. You don’t need to put each on a separate line as we have here—they can all go on the same line as long as some kind of whitespace is separating them. In the end, it’s your choice. The Template Tooolkit isn’t fussy about how you lay out your directives, as long as you follow the basic rules of syntax, which we’ll be introducing throughout this chapter and describing in greater detail in Chapter 3.
Comments
You can add comments to annotate your code, as shown in the second line of Example 2-7: # orange. A comment starts with the # character and continues to the end of the current line. The comment is ignored by the Template Toolkit, and processing continues as normal on the next line.
If # is used as the first character immediately following the opening [% tag, the Template Toolkit ignores the entire directive up to the closing %] :
[%# this is a comment
this line is also part of the comment
%]
Variable values
In Example 2-7, the four variables set are author, bgcol, year, and copyr. The first two are defined as the literal strings 'Arthur Dent' and '#FF6600' . The ' single quotation marks surrounding the values indicate that the contents should be used as provided. This makes it clear to the Template Toolkit that the # character in the definition for bgcol , for example, is part of the value and not the start of a comment. The third variable, year, is defined as the integer value 2003. Numbers such as these (and also floating-point numbers such as 2.718 ) don’t need to be quoted, but can be if you prefer.
The last variable, copyr , shows an example of a double-quoted string, in which the value is enclosed by " characters. Here the Template Toolkit looks for any references to variables embedded in the string, denoted by the $ character, and replaces (interpolates) them for the corresponding values. In this example, the values for year and author will be interpolated into the string, resulting in the copyr variable being set to "Copyright 2003 Arthur Dent" .
 |
If you've enjoyed what you've seen here, or to get more information, click on the "Buy the book!" graphic. Pick up a copy today!
Visit the O'Reilly Network http://www.oreillynet.com for more online content. |
|
/ 31 
