The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

GENERATING STATIC PAGES

Having created a template file we can now process it to generate some real output. The quickest and easiest way to do this is to use the tpage script. This is provided as part of the Template Toolkit and should be installed in your usual Perl bin directory.

Assuming you saved your template file as 'mypage.html', you would run the command:

    tpage mypage.html

This will process the template file, sending the output to STDOUT (i.e. whizzing past you on the screen). You may want to redirect the output to a file but be careful not to specify the same name as the template file, or you'll overwrite it. You may want to use one prefix for your templates such as '.atml' (for 'Another Template Markup Language', perhaps?) and the regular '.html' for the output files (assuming you're creating HTML, that is). Alternatively, you might redirect the output to another directory. e.g.

    tpage mypage.atml > mypage.html
    tpage templates/mypage.html > html/mypage.html

The tpage script is very basic and only really intended to give you an easy way to process a template without having to write any Perl code. A much more flexible tool is ttree, described below, but for now let's look at the output generated by processing the above example (some whitespace removed for brevity):

    <html>
    <head>
    <title>This is an HTML example</title>
    </head>
    
    <body bgcolor="#ffffff">
    
    <h1>Some Interesting Links</h1>
    
    Links:
    <ul>
       <li><a href="http://foo.org">The Foo Organsiation</a>
       <li><a href="http://bar.org">The Bar Organsiation</a>
    </ul>
    
    <hr>
    
    <center>
    &copy; Copyright 2000 Me, Myself, I
    </center>
    
    </body>
    </html>

The header and footer template files have been included (assuming you created them and they're in the current directory) and the link data has been built into an HTML list.

The ttree script, also distributed as part of the Template Toolkit, provides a more flexible way to process template documents. The first time you run the script, it will ask you if it should create a configuration file, usually called '.ttreerc' in your home directory. Answer 'y' to have it create the file.

The ttree documentation describes how you can change the location of this file and also explains the syntax and meaning of the various options in the file. Comments are written to the sample configuration file which should also help.

    perldoc ttree
    ttree -h

In brief, the configuration file describes the directories in which template files are to be found (src), where the corresponding output should be written to (dest), and any other directories (lib) that may contain template files that you plan to INCLUDE into your source documents. You can also specify processing options (such as 'verbose' and 'recurse') and provide regular expression to match files that you don't want to process (ignore, accept) or should be copied instead of processed (copy).

An example .ttreerc file is shown here:

$HOME/.ttreerc: verbose recurse

    # this is where I keep other ttree config files
    cfg = ~/.ttree

    src  = ~/websrc/src
    lib  = ~/websrc/lib
    dest = ~/public_html/test

    ignore = \b(CVS|RCS)\b
    ignore = ^#

You can create many different configuration files and store them in the directory specified in the 'cfg' option, shown above. You then add the -f filename option to ttree to have it read that file.

When you run the script, it compares all the files in the 'src' directory (including those in sub-directories if the 'recurse' option is set), with those in the 'dest' directory. If the destination file doesn't exist or has an earlier modification time than the corresponding source file, then the source will be processed with the output written to the destination file. The -a option forces all files to be processed, regardless of modification times.

The script doesn't process any of the files in the 'lib' directory, but it does add it to the INCLUDE_PATH for the template processor so that it can locate these files via an INCLUDE or PROCESS directive. Thus, the 'lib' directory is an excellent place to keep template elements such as header, footers, etc., that aren't complete documents in their own right.

You can also specify various Template Toolkit options from the configuration file. Consult the ttree documentation and help summary (ttree -h) for full details. e.g.

$HOME/.ttreerc: pre_process = config interpolate post_chomp

The 'pre_process' option allows you to specify a template file which should be processed before each file. Unsurprisingly, there's also a 'post_process' option to add a template after each file. In the fragment above, we have specified that the 'config' template should be used as a prefix template. We can create this file in the 'lib' directory and use it to define some common variables, including those web page links we defined earlier and might want to re-use in other templates. We could also include an HTML header, title, or menu bar in this file which would then be prepended to each and every template file, but for now we'll keep all that in a separate 'header' file.

$lib/config: [% root = '~/abw' home = "$root/index.html" images = "$root/images" email = 'abw@kfs.org' graphics = 1 webpages = [ { url => 'http://foo.org', title => 'The Foo Organsiation' } { url => 'http://bar.org', title => 'The Bar Organsiation' } ] %]

Assuming you've created or copied the 'header' and 'footer' files from the earlier example into your 'lib' directory, you can now start to create web pages like the following in your 'src' directory and process them with ttree.

$src/newpage.html: [% INCLUDE header title = 'Another Template Toolkit Test Page' %]

    <a href="[% home %]">Home</a>
    <a href="mailto:[% email %]">Email</a>

    [% IF graphics %]
    <img src="[% images %]/logo.gif" align=right width=60 height=40>
    [% END %]

    [% INCLUDE footer %]

Here we've shown how pre-defined variables can be used as flags to enable certain feature (e.g. 'graphics') and to specify common items such as an email address and URL's for the home page, images directory and so on. This approach allows you to define these values once so that they're consistent across all pages and can easily be changed to new values.

When you run ttree, you should see output similar to the following (assuming you have the verbose flag set).

  ttree 1.14 (Template Toolkit version 1.02a)

        Source: /home/abw/websrc/src
   Destination: /home/abw/public_html/test
  Include Path: [ /home/abw/websrc/lib ]
        Ignore: [ \b(CVS|RCS)\b, ^# ]
          Copy: [  ]
        Accept: [ * ]

    + newpage.html

The '+' before 'newpage.html' shows that the file was processed, with the output being written to the destination directory. If you run the same command again, you'll see the following line displayed instead showing a '-' and giving a reason why the file wasn't processed.

    - newpage.html                     (not modified)

It has detected a 'newpage.html' in the destination directory which is more recent than that in the source directory and so hasn't bothered to waste time re-processing it. To force all files to be processed, use the -a option. You can also specify one or more filenames as command line arguments to ttree:

    tpage newpage.html

This is what the destination page looks like.

$dest/newpage.html: <html> <head> <title>Another Template Toolkit Test Page</title> </head>

    <body bgcolor="#ffffff">
        
    <a href="~/abw/index.html">Home</a>
    <a href="mailto:abw@kfs.org">Email me</a>

    <img src="~/abw/images/logo.gif" align=right width=60 height=40>
        
    <hr>
    
    <center>
    &copy; Copyright 2000 Me, Myself, I
    </center>
    
    </body>
    </html>

You can add as many documents as you like to the 'src' directory and ttree will apply the same process to them all. In this way, it is possible to build an entire tree of static content for a web site with a single command. The added benefit is that you can be assured of consistency in links, header style, or whatever else you choose to implement in terms of common templates elements or variables.