This brings us nicely back to where we started, looking at the basic principle of template processing: separating your data from the way it is presented. It’s not always clear where your data belongs: in a configuration template; defined in a Perl script; or perhaps stored in a SQL database or XML file. Sometimes you’ll want to begin by defining some simple variables in a configuration template so that you can start designing the layout and look and feel of the site. Later on, you might choose to define that data somewhere else, passing it in from a Perl script or making it available through a plugin.

The beauty of the Template Toolkit is that it really doesn’t matter. It abstracts the details of the underlying implementation behind the uniform dotted notation for accessing data so that your templates keep working when your storage requirements change, as they inevitably will for many web sites.

It also makes it easy to include things such as loops, conditional statements, and other templates as easy as possible so that you can concentrate on presentation, rather than getting bogged down in the more precise details of full-blown programming language syntax. This is what we mean when we describe the Template Toolkit as a presentation language rather than a programming language.

It is an example of a domain-specific language that in many ways is similar to SQL, which is a domain-specific language for formulating database queries. As such, it should generally be used for what it is good at, rather than being contorted into doing something that might be a lot easier in another language. That doesn’t mean that you can’t use the Template Toolkit to do CGI programming, embed Perl, or even write Vogon poetry, if that’s your thing, but that’s not necessarily where its particular strengths lie. *

And that’s where Perl comes in. The Template Toolkit is designed to integrate with Perl code as cleanly and as easily as possible. When you want to do something more than the Template Toolkit provides, it is easy to append your own additions using a real programming language such as Perl. The plugin mechanism makes it easy to load external Perl code into templates so that you’re not always writing Perl wrapper scripts just to add something of your own.

However, this total separation is not something that the Template Toolkit enforces, although the default settings for various configuration options such as EVAL_PERL do tend to encourage it. Sometimes you just want to define a simple Perl subroutine in a template, for example, and don’t want to bother with a separate Perl script or plugin module. The Template Toolkit gives you the freedom to do things such as this when you really want to.

* Although the jury is still grooping hooptiously at the implorations of generating Vogon Poetry using the Template Toolkit.

For example, by enabling the EVAL_PERL option (see Chapter 4 and the Appendix for details), we can quickly define a Perl subroutine and bind it to a template variable, using a PERL block such as the following:

[% PERL %]
$stash->set( help => sub {
  my $entry = shift;
  return "$entry: mostly harmless";
} );
[% END %]

The $stash->set( var => $value ) code, shown here binding the help variable to the Perl subroutine, is the Perl equivalent of writing [% var = value %] in a template— except, of course, that you can’t usually define a subroutine directly in a template, only by using Perl code with EVAL_PERL set (which we think is a sensible restriction). This block can easily be defined in a preprocessed configuration template to keep it out of harm’s way, leaving the template authors to use the simple variable:

[% help('Earth') %]

The important thing is to achieve an appropriate separation of concerns, rather than a total separation of concerns. Sometimes it’s easier to define everything in one template or Perl program and to use a clear layout to separate the different parts. Splitting a small and self-contained document into several different pieces, each comprising just one part of the jigsaw puzzle, can make it hard to see the big picture. On the other hand, a more complex web site may have bigger pieces that absolutely need to be maintained in isolation from the other parts. Remember, there is no golden rule, so the Template Toolkit doesn’t try and enforce one on you.

The techniques that we’ve taught you in this chapter will allow you to address most, if not all, of the simple but common problems that you’ll typically face when building and maintaining a web site. We’ll be coming back to the Web in Chapter 11 to look at some further ways in which the Template Toolkit can be used to enhance your site and make your life easier. In Chapter 12, we’ll be showing how it can be used to handle the presentation layer to simplify the process of building and customizing web applications. 

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.