[% TAGS [** **] -%]
=head1 DESCRIPTION

The Template module is a simple front-end to the Template Toolkit.  It
implements a generic template processing object which loads and uses
other Template Toolkit modules as required to process template
documents.

    use Template;
    my $tproc = Template->new();

Constants defined in Template::Constants can be imported by specifying
import tag sets as parameters to the C<use Template> statement.

    use Template qw( :status );

The object may be configured by passing a hash reference to the new()
constructor.

    my $tproc = Template->new({
        INTERPOLATE => 1,
        PRE_CHOMP   => 1,
    });

Templates are rendered by calling the process() method on the Template
object.  The first parameter specifies the template input and may be a
filename, a reference to a text string (SCALAR) containing template
text or a reference to a GLOB or IO::Handle (or sub-class) from which
the template should be read.  The method returns 1 if the template
was successfully processed or 0 if an error occurred.  In the latter
case, the relevant error message can be retrieved by calling the
error() method.

    $tproc->process($myfile)
        || die $tproc->error(), "\n";

The second optional parameter may be a hash reference which defines
variables for use in the template.  The entries in this hash may be
simple values, references to hashes, lists, sub-routines or objects
(described in detail below).

    my $data = {
        'name' => 'John Doe'
        'id'   => 'jdoe',
    };

    $tproc->process($myfile, $data) 
        || die $tproc->error(), "\n";

The PRE_PROCESS and POST_PROCESS options may be used to specify the
name(s) of template file(s) that should be processed immediately
before and after each template, respectively.  This can be used to add
page headers and footers, for example.

=head1 TEMPLATE SYNTAX AND DIRECTIVES

=head2 DIRECTIVE TAGS

The default syntax for embedding directives in template documents is
to enclose them within the character sequences '[%' and '%]'.

    [% INCLUDE header %]
  
    <h1>Hello World!</h1>
    <a href="[% page.next %]"><img src="[% icon.next %].gif"></a>
  
    [% INCLUDE footer %]

For backwards compatibility with Text::MetaText, the default TAG_STYLE
also allows the '%%' token to be used as both the start and end of
tags.

    %% INCLUDE header %%    # for backwards compatibility

You can change the tag characters using the START_TAG, END_TAG and 
TAG_STYLE options, described below.  You can also use the TAGS directive
to change the tags on a per-file basis.  The new tag definitions last
only for the current template file.  The TAGS directive should contain
either a TAG_STYLE name or two whitespace delimited character sequences 
to represent the START and END tags.

    [% TAGS html %]
    <!-- INCLUDE header title = 'Hello World!' -->

or    

    [% TAGS <!-- --> %]
    <!-- INCLUDE header title = 'Hello World!' -->

Directives may be embedded anywhere in a line of text and can be split 
across several lines.  Whitespace is generally ignored within the 
directive, except where used to separate parameters.

    [% INCLUDE header		   
       title  = 'Hello World' 
       bgcol  = '#ffffff' 
    %]
  
    [%INCLUDE menu align='right'%]
  
    Name: [% name %]  ([%id%])

Directives that start with a '#' are treated as comments and ignored.
No output is generated.  This is useful for commenting template documents
or temporarily disabling certain directives.
 
    [% # This is a comment and will be ignored %]

=head2 CLEANING UP WHITESPACE

Anything outside a directive tag is considered plain text and is
generally passed through unaltered (but see INTERPOLATE below).  This
includes all the whitespace and newlines characters surrounding
directive tags.  When tags are processed, they may generate no output
but leave a 'gap' in the output document.

Example:

    Foo
    [% a = 10 %]
    Bar

Output:

    Foo

    Bar

The PRE_CHOMP and POST_CHOMP options help to reduce this extraneous
whitespace.  If a directive appears at the start of a line, or on a
line with nothing but whitespace in front of it, then a PRE_CHOMP will
delete any whitespace and the preceding newline character.  This
effectively moves the directive up onto the previous line.  When a
directive appears at the end of a line, or on a line with nothing but
whitespace following it, then a POST_CHOMP will delete any whitespace
and the following newline.  This effectively moves the next line up
onto the current line.  

 	Foo <----------.
 		       |
    ,---(PRE-CHOMP)----'
    |
    `-- [% a = 10 %] --.
 		       |
    ,---(POST-CHOMP)---'
    |
    `-> Bar

The '-' or '+' processing flags may be added immediately inside the 
start/end tags to enable or disable pre/post chomping options on a 
per-directive basis.

    [%  a = b  %]   # default PRE_CHOMP and POST_CHOMP
    [%- a = b  %]   # do PRE_CHOMP  (remove start of line if blank)
    [%  a = b -%]   # do POST_CHOMP (remove rest of line if blank)
    [%+ a = b  %]   # don't PRE_CHOMP  (leave start of line intact)
    [%  a = b +%]   # don't POST_CHOMP (leave rest of line intact)

See the PRE_CHOMP and POST_CHOMP configuration options, described below.

=head2 VARIABLES

Directives generally comprise a keyword such as INCLUDE, FOREACH, IF,
etc., possibly followed by one or more expressions, parameters, etc.

The GET and SET directives are provided to retrieve (print) and update
variable values, respectively.  For the sake of brevity, the GET and
SET keywords can be omitted and a lone variable will be implicitly
treated as a GET directive while an assignment, or sequence of
assignments will be implicitly treated as a SET directive.

    # explicit
    [% GET foo %]
    [% SET bar=baz %]
    [% SET 
       name  = 'Fred'
       email = 'fred@happy.com'
    %]
   
    # implicit (preferred)
    [% foo %]
    [% bar=baz %]
    [% name  = 'Fred'
       email = 'fred@happy.com'
    %]

The DEFAULT directive is similar to SET but only updates variables 
that are currently undefined or have no "true" value (in the Perl
sense).

    [% DEFAULT
       name = 'John Doe'
       id   = 'jdoe'
    %]

The CALL directive is similar to GET in evaluating the variable named,
but doesn't print the result returned.  This can be useful when a
variable is bound to a sub-routine or object method which you want to
call but aren't interested in the value returned (especially if it
returns 0 or some other status code).  See L<VARIABLES BOUND TO USER
CODE> and L<VARIABLES BOUND TO OBJECTS> below, for further details.

    [% CALL inc_page_counter %]

The INTERPOLATE option allows you to embed variables directly into text
without requiring the '[%' and '%]' tags.  Instead, the variable name 
should be prefixed by a '$'.  You can use curly braces to explicitly 
delimit the variable name when required:

    # INTERPOLATE => 1
    <a href="$page.next"><img src="${icon.next}.gif"></a>

With INTERPOLATE set on, any other '$' characters in your document should 
be 'escaped' by prefixing them with a '\':

    Cost: \$100

=head2 BLOCK DIRECTIVES

The FOREACH, WHILE, BLOCK, FILTER, CATCH and PERL directives mark the start
of a block which may contain text or other directives (including other
nested blocks) up to the next (balanced) END directive.  The IF,
UNLESS, ELSIF and ELSE directives also define blocks and may be
grouped together in the usual manner.

    [% FOREACH item = [ 'foo' 'bar' 'baz' ] %]
       * Item: [% item %]
    [% END %]
  
    [% BLOCK footer %]
       Copyright 1999 [% me %]
       [% INCLUDE company/logo %]
    [% END %]
  
    [% CATCH file %]
       <!-- File error: [% e.info %] -->
       [% IF debugging %]
  	  [% INCLUDE debugtxt  msg = "file: $e.info" %]
       [% END %]
    [% END %]
  
    [% IF foo %]
       do this...
    [% ELSIF bar %]
       do that...
    [% ELSE %]
       do nothing...
    [% END %]

=head2 DIRECTIVE SYNTAX AND STRUCTURE

Multiple directives may be included within a single tag by separating 
them with semi-colons.

    [% IF debugging; 
  	 INCLUDE debugtxt  msg = "file: $e.info;
       END 
    %]

Note that the TAGS directive must always be specified in a tag by itself.

The IF, UNLESS, FOREACH, WHILE and FILTER block directives may be
specified immediately after another directive (except other block
directives) in a convenient 'side-effect' notation.

    [% INCLUDE userinfo FOREACH user = userlist %]
    [% INCLUDE debugtxt msg="file: $e.info" IF debugging %] 
    [% "Danger Will Robinson" IF atrisk %]

The directive keyword may be specified in any case but you might find 
that it helps to adopt the convention of always using UPPER CASE to 
make them visually distinctive from variables.  

    [% FOREACH item = biglist %]   # Good.  
    [% foreach item = biglist %]   # OK, but not recommended

Variable names may contain any alphanumeric characters or underscores.
They may be lower, upper or mixed case although the usual convention
is to use lower case.  The case I<is> significant however, and 'foo',
'Foo' and 'FOO' are all different variables.

The fact that a keyword may be expressed in any case, precludes you from
using any variable that has the same name as a reserved word, irrespective
of its case.  Reserved words are:

    GET, SET, CALL, DEFAULT, INCLUDE, PROCESS, IMPORT, FILTER, USE
    FOR, FOREACH, IF, UNLESS, ELSE, ELSIF, AND, OR, NOT 
    BLOCK, MACRO, END, THROW, CATCH, ERROR, RETURN, STOP, PERL
    DEBUG

e.g.

    [% include = 10 %]   # error - 'INCLUDE' a reserved word

The CASE option forces all directive keywords to be expressed in UPPER
CASE.  Any word not in UPPER CASE will be treated as a variable.  This
then allows you to use lower, or mixed case variable names that match
reserved words.  The CASE option does not change the case sensitivity
for variable names, only reserved words.  Variable names are always
case sensitive.  The 'and', 'or' and 'not' operators are the only
exceptions to this rule.  They can I<always> be expressed in lower, or
indeed any case, irrespective of the CASE option, and as such,
preclude the use of a variables by any of those names.

    # CASE => 1
    [% include = 10 %]     # OK - 'include' is a variable, 'INCLUDE' 
  			   # is the reserved word.
    [% INCLUDE foobar      
  	 IF foo and bar    # OK - 'and' can always be lower case
    %]

=head2 VARIABLE NAMESPACES (HASHES)

The period character, '.', is used to construct compound ("dotted")
variables .  Each element denotes a separate variable "namespace"
which is simply a variable that contains a reference to a hash array
of more variables.

    my $data = {
  	'home' => 'http://www.myserver.com/homepage.html',
  	'user' => {
  	    'name' => 'John Doe',
  	    'id'   => 'jdoe',
  	},
  	'page' => {
  	    'this' => 'mypage.html',
  	    'next' => 'nextpage.html',
  	    'prev' => 'prevpage.html',
  	},
    };
  
    $tproc->process($myfile, $data) 
  	|| die $tproc->error(), "\n";

Example:

    <a href="[% home %]">Home</a>
    <a href="[% page.prev %]">Previous Page</a>
    <a href="[% page.next %]">Next Page</a>

Output:

    <a href="http://www.myserver.com/homepage.html">Home</a>
    <a href="prevpage.html">Previous Page</a>
    <a href="nextpage.html">Next Page</a>

Any key in a hash which starts with a '_' or '.' character will be 
considered 'private' and cannot be evaluated or updated from within 
a template.

When you assign to a variable that contains multiple namespace 
elements (i.e. it has one or more '.' characters in the name),
any hashes required to represent intermediate namespaces will be 
created automatically.  In other words, you don't have to explicitly
state that a variable ('product' in the next example) will represent
a namespace (i.e. reference a hash), you can just use it as such
and it will be created automatically.

    [% product.id    = 'XYZ-2000' 
       product.desc  = 'Bogon Generator'
       product.price = 666 
    %]
   
    # INTERPOLATE => 0
    The [% product.id %] [% product.desc %] 
    costs $[% product.price %].00

Output:

    The XYZ-2000 Bogon Generator 
    costs $666.00

If you want to create a new variable namespace (i.e. a hash) en masse,
then you can use Perl's familiar '{' ... '}' construct to create a 
hash and assign it to a variable.

    [% product = {
  	 id    = 'XYZ-2000' 
  	 desc  = 'Bogon Generator'
  	 price = 666 
       }
    %]
   
    # INTERPOLATE => 1
    The $product.id $product.desc 
    costs \$${product.price}.00

Output:

    The XYZ-2000 Bogon Generator 
    costs $666.00

Note that commas are optional between key/value pairs and the '=>' token
may be used in place of '='.

The 'keys' and 'values' methods may be applied to any hash to return 
lists of the hash keys and values.

    [% FOREACH field = product.keys %]
       [% field %] [% product.${field} %]
    [% END %]

This example also shows how a variable ('field' in this case) may be 
evaluated as '${field}' to return a value which is then used to index
into the 'product' hash array.

The FOREACH directive can also be used to iterate through the items in 
the hash.  Each entry in the hash is returned in sorted order (based on 
the key) as a hash array containing 'key' and 'value' items.

    [% users = {
	 tom   => 'Thomas',
	 dick  => 'Richard',
         harry => 'Harold',
       }
    %]

    [% FOREACH u = users %]
       * [% u.key %] : [% u.value %]
    [% END %]

Output:

       * dick : Richard
       * harry : Harold
       * tom : Thomas      

You can copy all the members of a hash into the top level variable namespace
with the IMPORT directive.

    [% user = {
  	 name = 'John Doe'
  	 id   = 'jdoe'
       }
    %]
   
    [% IMPORT user %] 
    Name: [% name %]   ID: [% id %]

You can automatically IMPORT a hash when INCLUDE'ing another template
file or block by assigning it to the upper case IMPORT variable, passed
as a parameter.

    [% BLOCK one %]
       [% user.name %] [% user.email %]
    [% END %]
  
    [% BLOCK two %]
       [% name %] [% email %]
    [% END %]
  
    [% user  = { name = 'me',  email = 'me@here.com'   }
       other = { name = 'you', email = 'you@there.com' }
    %]
  
    [% INCLUDE one %]
    [% INCLUDE one user=other %]
    [% INCLUDE two IMPORT=user %]
    [% INCLUDE two IMPORT=other %]

=head2 VARIABLE VALUES 

Variables may be assigned the values of other variables, unquoted
numbers (digits), literal text ('single quotes') or quoted text
("double quotes").  In the latter case, any variable references within
the text will be interpolated when the string is evaluated.  Variables
should be prefixed by '$', using curly braces to explicitly scope
variable name where necessary.

    [% foo  = 'Foo'  %]               # literal value 'Foo'
    [% bar  =  foo   %]               # value of variable 'foo'
    [% cost = '$100' %]               # literal value '$100'
    [% item = "$bar: ${cost}.00" %]   # value "Foo: $100.00"

Multiple variables may be assigned in the same directive and are 
evaluated in the order specified.  Thus, the above could have been 
written:

    [% foo  = 'Foo'
       bar  = foo
       cost = '$100'
       item = "$bar: ${cost}.00"
    %]

The basic binary mathematic operators (+ - * div and mod) can also be used.

    [% ten    = 10 
       twenty = 20
       thirty = twenty + ten
       forty  = 2 * twenty 
       fifty  = 100 div 2
       six    = twenty mod 7
    %]

=head2 VARIABLE LISTS

A list (actually a reference to an anonymous Perl list) can be created
and assigned to a variable by enclosing one or more values in square
brackets, just like in Perl.  The values in the list may be any of
those described above.  Commas between elements are optional.

    [% userlist = [ 'tom' 'dick' 'harry' ] %]

    [% foo    = 'Foo'
       mylist = [ foo, 'Bar', "$foo Baz" ]
    %]

You can also create simple numerical sequences using the familiar '..'
operator:

    [% n = [ 1 .. 4 ] %]    # 'n' is [ 1, 2, 3, 4 ] 

    [% x = 4
       y = 8
       z = [x..y]           # 'x' is [ 4, 5, 6, 7, 8 ]
    %]

The FOREACH directive will iterate through a list created as above, or
perhaps provided as a pre-defined variable passed to the process() method.

    my $data = {
  	'name' => 'John Doe'
  	'id'   => 'jdoe',
  	'items' => [ 'one', 'two', 'three' ],
    };
  
    $tproc->process($myfile, $data) 
  	|| die $tproc->error(), "\n";

Example:

    Things:
    [% foo = 'Foo' %]
    [% FOREACH thing = [ foo 'Bar' "$foo Baz" ] %]
       * [% thing %]
    [% END %]
  
    Items:
    [% FOREACH i = items %]
       * [% i %]
    [% END %]
  
    Stuff:
    [% stuff = [ foo "$foo Bar" ] %]
    [% FOREACH s = stuff %]
       * [% s %]
    [% END %]

Output:

    Things:
      * Foo
      * Bar
      * Foo Baz
  
    Items:
      * one
      * two
      * three
  
    Stuff:
      * Foo
      * Foo Bar

When the FOREACH directive is used without specifying a target variable, 
any iterated values which are hash references will be automatically 
imported.

    # assume 'userlist' is a list of user hash refs
    [% FOREACH user = userlist %]
       [% user.name %]
    [% END %]
  
    # same as...
    [% FOREACH userlist %]
       [% name %]
    [% END %]

Note that this particular usage creates a localised variable context
to prevent the imported hash keys from overwriting any existing
variables.  The imported definitions and any other variables defined
in such a FOREACH loop will be lost at the end of the loop, when the 
previous context and variable values are restored.

The [% BREAK %] directive can be used to prematurely exit a FOREACH
loop.

    [% FOREACH user = userlist %]
       [% user.name %]
       [% BREAK IF some.condition %]
    [% END %]

Individual elements of the list can be referenced by a numerical suffix.
The first element of the list is element 0.

    [% list = [ 'one' 'two' 'three' 'four' ] %]
    [% list.0 %] [% list.3 %]

    [% FOREACH n = [0..3] %]
    [% list.${n} %], 
    [%- END %]

Output:
    one four
    one, two, three, four, 

Several general purpose methods are defined for accessing elements or
otherwise manipulating lists.

=over 4

=item size

Returns the number of items in the list.

=item max

Returns the index number of the last entry in the list (size - 1).  

=item first

Returns the first item in the list. 

=item last

Returns the last item in the list. 

=item sort

Returns the list items in basic sorted order (using Perl's 'sort').

=item join

Returns all elements in the list joined into a single string.  A joining
string can be specified as a parameter.

=back

Example 1:

    [% list = [ 'Tom', 'Dick', 'Harry' ] %]
    [% FOREACH name = list.sort %]
       * [% name %]
    [% END %]

    or: [% list.sort.join(', ') %]

Output:

    3 names:
      * Dick
      * Harry
      * Tom

    or: Dick, Harry, Tom

Example 2:

    [% items  = [ 'alpha', 'bravo', 'charlie', 'whisky', 'zulu' ] %]
    [% items.size %] entries ([% items.first %] - [% items.last %]):
       -> [% items.join(', ') %]

Output:

    5 entries (alpha - zulu):
       -> alpha, bravo, charlie, whisky, zulu


=head2 VARIABLES BOUND TO USER CODE

Template variables may also contain references to Perl sub-routines
(CODE).  When the variable is evaluated, the code is called and the
return value used in the variable's place.  These "bound" variables
can be used just like any other:

    my $data = {
  	'magic' => \&do_magic,
    };
  
    $template->process('myfile', $data)
  	|| die $template->error();
  
    sub do_magic {
  	# ...whatever...
  	return 'Abracadabra!';
    }

myfile:

    He chanted the magic spell, "[% magic %]", and 
    disappeared in a puff of smoke.

Output:

    He chanted the magic spell, "Abracadabra!", and
    disappeared in a puff of smoke

In this example, the [% magic %] variable is bound to the do_magic()
sub-routine.  The code is called and the return value, 'Abracadabra',
inserted into the document in place of the directive.  The CALL
directive can be used to evaluate a variable (e.g. call code or an 
object method) without printing the returned result.

   [% CALL some_code %]

Any additional parameters specified in parenthesis will also be passed
to the code:

    $data = {
	'foo'   => 'Mr. Foo',
	'bar'   => 'Mr. Bar',
	'qux'   => 'Qux',
	'bold'  => sub { my $text = shift; return "<b>$text</b>"; },
    }

    $template->process('myfile', $data)
	|| die $template->error();

myfile:

    [% bold('face') %]

Output:

    <b>face</b>

Named parameters may also be specified.  These are automatically collected
into a single hash array which is passed by reference as the B<last> 
parameter to the sub-routine.  Note how '=>' is synonymous for '='.

    [% whatever(foo, bar, name = 'John Doe', id = 'jdoe') %]

       # calls whatever('Mr. Foo', 'Mr. Bar', 
		        { name => 'John Doe', id => 'jdoe' });

    [% whatever(name => 'John Doe', id => 'jdoe') %]

       # calls whatever({ name => 'John Doe', id=>'jdoe' });

    [% whatever(10, name='John Doe', 20, id='jdoe') %]

       # calls whatever(10, 20, { name => 'John Doe', id=>'jdoe' });

The last example demonstrates the re-ordering of parameters. For the sake
of clarity, it is recommended that you specify named parameters at the 
end of the list.

    [% whatever(10, 20, name='John Doe', id='jdoe') %]

Parenthesised parameters may be added to I<any> element of a variable,
not just those that are bound to code or object methods.  At present,
parameters will be ignored if the variable isn't "callable" but are 
supported for future extensions.  Think of them as "hints" to that 
variable, rather than just arguments passed to a function.

    [% r = 'Romeo' %]
    [% r(100, 99, s, t, v) %]     # still just prints "Romeo"

User code should return a value for the 'variable' to which it is
bound.  Examples:

    return 'foo';
    return [ 'foo', 'bar' ];
    return $myobj;

If a sub-routine returns multiple values of which the first has some
defined value, then the entire list will be folded into a list reference
and taken as the value for the variable to which it is bound.  Thus, 
the following are roughly equivalent:

    return ('foo', 'bar', 'baz');
    return ['foo', 'bar', 'baz'];

An undefined value may be returned by itself and will silently
be converted to an empty string unless the DEBUG option is enabled, in
which case an 'undef' exception will be raised.  Where an undefined
value is returned followed by another value, then that second value
is taken to indicate an error condition.  This may be in the form
of a status code, an error string or a Template::Exception object
reference.  Note that returning an undefined first value disables
the automatic list folding described above.

    return (undef, STATUS_OK);              # no error
    return (undef, STATUS_STOP);            # stop
    return (undef, 'something failed');     # general error
    return (undef, Template::Exception->new('DBI', $DBI::Errstr));

A status code of 0 (STATUS_OK) means everything went OK, and there's
no error to raise.  The status code can also be STATUS_STOP (immediate
stop) or STATUS_RETURN (stop the current template only and return to
the caller or point of INCLUDE).  A text string returned, such as in
the third example above, is converted into a Template::Exception of
type 'undef'.  Template::Exception objects can also be returned
directly as shown in the last example.

The CATCH option and CATCH block directive allow you to define custom
handling, or template blocks to be processed when different kinds of 
exception occur, including any user-defined types such as in this 
example:

    use Template qw( :status );
    use Template::Exception;
  
    my $tproc = Template->new();
    $tproc->process('example', { sql => \&silly_query_language })
      || die $tproc->error(), "\n";
  
    sub silly_query_language {
  	# some code...
  
  	# stop!
  	return (undef, STATUS_STOP) if $some_fatal_error;
  
  	# some more code...
  
  	# raise a 'database' exception that might be caught and handled
  	return (undef, 
	        Template::Exception->new('database', $DBI::errstr))
  	    if $dbi_error_occurred;
  
  	# even more code still..
  
  	# OK, everything's just fine.  Return data
  	return $some_data;
    }

Example:

    [% # define a CATCH block for 'database' errors that 
       # prints the error, adds the page footer and STOPs  
    %]
    [% CATCH database %]
       <!-- Database error handler -->
       <hr>
       <h1>Database Error</h1>
       An unrecoverable database error has occurred:
       <ul>
  	 [% e.info %]
       </ul>
       [% INCLUDE footer %]
       [% STOP %]
    [% END %]
  
    [% # we're prepared for the worst... %]
    [% sql('EXPLODE my_brain INTO a_thousand_pieces') %] 


=head2 VARIABLES BOUND TO OBJECTS

A variable may contain an object reference whose methods will be
called when expressed in the 'object.method' notation.  The object
reference will implicitly be passed to the method as the first parameter.
Any other parameters specified in parenthesis after the method name
will also be passed.

    package MyObj;
  
    sub new {
  	my $class  = shift;
  	bless { }, $class;
    }
  
    sub bar {
      my ($self, @params) = @_;
      # do something...
      return $some_value; 
    }
  
    package main;
  
    my $tproc = Template->new();
    my $obj   = MyObj->new();
    $tproc->process('example', { 'foo' => $obj, 'baz' => 'BAZ' } )
      || die $tproc->error(), "\n";

Example:

    [% foo.bar(baz) %]	# calls $obj->bar('BAZ')

Methods whose names start with an underscore (e.g. '_mymethod') will not
be called.  Parameter passing and return value expectations are as per
code references, above.

=head2 VARIABLE EVALUATION

A compound 'dotted' variable may contain any number of separate
elements.  Each element may evaluate to one of the above variable
types and the processor will then correctly use this value to evaluate
the rest of the variable.

For example, consider the following variable reference:

    [% myorg.user.abw.name %]

This might equate to the following fundamental steps:

    'myorg'  is an object reference
    'user'   is a method called on the above object returning another
             object which acts as an interface to a database
    'abw'    is a method called on the above object, caught by AUTOLOAD
             triggering the retrieval of a record from the database.  
             This is returned as a hash
    'name'   is fetched from this hash, representing the value of the 
             'name' field in the record.

You don't need to worry about any of the above steps because they all
happen automatically. When writing a template, a variable is just a
variable, irrespective of how its value is stored, retrieved or
calculated. 

Intermediate variables may be used and will behave entirely as expected.

    [% userdb = myorg.user %]
    [% user   = userdb.abw %]
    Name: [% user.name %]  EMail: [% user.email %]

An element of a dotted variable can itself be an interpolated value.
The variable should be enclosed within the '${' .., '}' characters.
In the following example, we use a 'uid' variable interpolated into 
a longer variable such as the above to return multiple user records
from the database. 

    [% userdb = myorg.user %]
    [% FOREACH uid = [ 'abw' 'sam' 'hans' ] %]
       [% user = userdb.${uid} %]
       Name: [% user.name %]  EMail: [% user.email %]
    %]

This could be also have been interpolated into the full variable reference:

    [% uid  = 'abw'
       name = myorg.user.${uid}.name
    %]

You can also use single and double quoted strings inside an 
interpolated element:

    # contrived example
    [% letterw = 'w' 
       name = myorg.user.${"ab$letterw"}.name
    %]

Any namespace element in a variable may contain parenthesised parameters.
If the item contains a code reference or represents an object method then
the parameters will be passed to that sub-routine/method when called.
Parameters are otherwise ignored, but may be used for future 
extensibility.

A different implementation of the above example might look like this:

    [% myorg.user('abw').name %]

Here, the fictional 'user' method of the 'myorg' object takes a
parameter to indicate the required record.  Thus, it can directly
return a hash reference representing the record which can then be
examined for the 'name' member.  The method could be written to check
for the existence of a parameter and return a general access facility,
such as the object mentioned in the previous example, if one is not
provided.

    package MyObj;
  
    sub user {
  	my ($self, $uid) = @_;
  	return $uid ? $self->get_record($uid) : $self
    }

    sub AUTOLOAD {
	my ($self, @params) = @_;
        my $name = $AUTOLOAD;
        $name =~ s/.*:://;
        return if $name eq 'DESTROY';
        $self->get_record($name);
    }

A sub-routine or method might also return a reference to a list containing
other objects or data.  The FOREACH directive is used to iterate through
such lists.

    [% FOREACH user = myorg.userlist %]
       Name: [% user.name %]  EMail: [% user.email %]
    [% END %]

For more powerful list iteration, a Template::Iterator object can be
created and returned for use in a FOREACH directive.  The following
pseudo-code example illustrates how a database iterator might perform.
The 'userlist' method first determines a list of valid user ID's from
a database table and then creates an iterator to step through them in
sequence.  On each iteration, the ACTION for the iterator is called,
which in this case is a closure which calls the user($uid) method to
retrieve the complete user record from the database.  Thus, we avoid
the overhead of loading and storing every complete user record,
retrieving them only as and when required.

    sub user {
  	my ($self, $uid) = @_;
  	return $self->query("SELECT * FROM user WHERE (uid='$uid')");
    }
  
    sub userlist {
  	my $self = shift;
  	my $user_id_list = $self->query("SELECT id FROM user");
  	return Template::Iterator->new($user_id_list, {
  	      ORDER  => 'sorted',
  	      ACTION => sub { $self->user(shift) },
  	});
    }

This process is entirely hidden from the template author.  The use of 
iterators is automatic and nothing needs to be changed in the template:

    [% FOREACH user = myorg.userlist %]
       Name: [% user.name %]  EMail: [% user.email %]
    [% END %]

A reference to the iterator is always available within a FOREACH 
block via the 'loop' variable.  An iterator is automatically created 
by the FOREACH directive if a regular list is specified.  The iterator
provides a number of methods for testing the state of the loop:
first() and last() return true if the iterator is on the first
or last iteration of the loop; size() and max() return the number of 
elements and maximum index (size - 1) for the list; and number() and 
index() return the current iteration offset from 1 and 0 respectively 
(i.e. number() runs from 1 to size(), index() runs from 0 to max())

    [% FOREACH user = myorg.userlist %]
       [% INCLUDE utab_header IF loop.first() %]
       <tr> 
         <td>[% loop.number %]</td> <td>[% user.name %]</td>
       </tr>
       [% "</table>" IF loop.last() %]
    [% END %]

    [% BLOCK utab_header %]
    <table>
    <th>Number</th> <th>Name</th>
    [% END %]


=head2 CONDITIONAL BLOCKS

The IF, ELSIF and UNLESS directives can be used to process or ignore a
block based on some run-time condition.  Multiple conditions may be
joined with ELSIF and/or ELSE blocks.

The following conditional and boolean operators may be used:

    == != < <= > >= ! && || and or not

Conditions may be arbitrarily complex and are evaluated left-to-right
with conditional operators having a higher precedence over boolean ones.  
Parenthesis may be used to explicitly determine evaluation order.

Examples:

    # simple example
    [% IF age < 10 %]
       Hello [% name %], does your mother know you're 
       using her AOL account?
    [% ELSE %]
       Welcome [% name %].
    [% END %]

    # ridiculously contrived complex example
    [% IF (name == 'admin' || uid <= 0) && (mode == 'debug' || debug) %]
       I'm confused.
    [% ELSIF more > less %]
       That's more or less correct.
    [% END %]

The WHILE directive can be used to repeatedly process a template block
while an expression (as per the examples above) evaluates "true".  

    [% WHILE total < 100 %]
       ....
       [% total = calculate_new_total %]
    [% END %]

An assignment can be enclosed in parenthesis to evaluate the assigned
value.

    [% WHILE (user = get_next_user_record) %]
       [% user.name %]
    [% END %]

The [% BREAK %] directive can be used to prematurely exit a WHILE
loop.

=head2 INCLUDING TEMPLATE FILES AND BLOCKS

The INCLUDE directive is used to process and include the output of
another template file or block.

    [% INCLUDE header %]

The first parameter to the INCLUDE directive is assumed to be the name
of a file or defined block (see BLOCK, below).  For convenience, it
does not need to be quoted as long as the name contains only
alphanumeric characters, underscores, dots or forward slashes.  Names
containing any other characters should be quoted.

    [% INCLUDE misc/menu.atml               %]
    [% INCLUDE 'dos98/Program Files/stupid' %]

To evaluate a variable to specify a file/block name, explicitly prefix 
it with a '$' or use double-quoted string interpolation.

    [% language = 'en'
       header   = 'test/html/header.html' 
    %]

    [% INCLUDE $header %]
    [% INCLUDE "$language/$header" %]

The processor will look for files relative to the directories specified in
the INCLUDE_PATH.  Each file is parsed when first loaded and cached 
internally in a "compiled" form.  The contents of the template, including
any directives embedded within it, will then be processed and the output
included into the current document.  Subsequent INCLUDE directives 
requesting the same file can then use the cached version to greatly 
reduce processing time.

You should I<always> use the '/'character as a path separator as shown
in the above examples, regardless of your local operating system
convention.  Perl will automatically convert this to the local
equivalent for non-Unix file systems.  The '/' character is therefore
portable across all platforms.

The included template will "inherit" all variables currently defined
in the including template.  Note how the 'title' and 'bgcol' variables
in this next example are used in the 'header' file, inheriting the
values defined previously in the including template.

    [% title = 'Hello World'
       bgcol = '#ffffff' 
    %]
    [% INCLUDE header %]

header:

    <html>
    <head><title>[% title %]</title></head>
    <body bgcolor="[% bgcol %]">

Output:

    <html>
    <head><title>Hello World!</title></head>
    <body bgcolor="#ffffff">

The DEFAULT directive can be useful for supplying default values in
commonly used template files such as this:

header:

    [% DEFAULT
       title = 'The "Hello World!" Web Site'
       bgcol = '#ffffff'
    -%]
    <html>
    <head><title>[% title %]</title></head>
    <body bgcolor="[% bgcol %]">

(Note how the DEFAULT directive specifies an explicit POST_CHOMP by 
placing a '-' immediately before the '%]' end-of-tag characters.  This
tells the processor to remove the whitespace and newline that immediately
follow the DEFAULT directive.  One place where additional whitespace can
cause problems in an HTML document is before the initial <html> tag, so 
we're sure to strip it out, just to be safe) 

Further parameters can be provided to define local variable values for 
the template.  

    [% INCLUDE header
       title = 'Cat in the Hat'
       bgcol = '#aabbcc'
    %]

Output:

    <html>
    <head><title>Cat in the Hat</title></head>
    <body bgcolor="#aabbcc">

These variables, along with any other B<non-compound> variables that
might be created or used within the I<included> template remain local
to it.  Changes made to them don't affect the variables in the
I<including> template, even though they may have inherited values from
them.

    [% name = 'foo' %] 
    [% INCLUDE change_name %]
    Name is still '[% name %]'

change_name:

    Name is [% name %]
    Changing '[% name %]' to [% name ='bar'; name %]

Output:

    Name is 'foo'
    Changing 'foo' to 'bar'
    Name is still 'foo'

Dotted compound variables behave slightly differently.  The
localisation process (known as "cloning the stash" but you won't be
tested on that) only copies top-level variables.  Any namespaces
already defined will be accessible within a localised context, but the
sub-namespace variables to which they refer will not be localised.  In
implementation terms, the references to hashes are copied, but the
copies refer to the same hash.  In more general terms, you can think
of a dotted variable as referring to the appropriate global variable
if (and only if) the top-level namespace (i.e. the first element of
the compound variable) is already defined.

Let's see if an example makes this any clearer:

    [% user = { name = 'John Doe' } %]
    [% INCLUDE change_name %]
    Name is: [% user.name %]

change_name:

    [% user.name = 'Jack Herer' %]

Output:

    Name is: Jack Herer

A namespace that isn't already defined will be created automatically
when used.  This B<does> remain local to the context of the current
template.  The following example demonstrates the kind of "unexpected"
behaviour that you might encounter if you find yourself trying to set a 
variable in a namespace that doesn't already exist.

    [% INCLUDE change_name %]   
    User: [% user.name %]           # not defined

change_name:

    [% user.name = 'Tom Thumb' %]

In the F<change_name> template, the 'user' variable is undefined so a 
namespace hash is created in the local context with a 'name' member set
to 'Tom Thumb'.  At the end of processing F<change_name>, the local
variables, including the 'user' namespace are deleted.  This is also the
case if an existing non-namespace variable exists.  A local namespace
will be created masking the previously defined value but only for the 
processing lifetime of that template.

    [% user = 'Tom Thumb' %]
    [% INCLUDE change_name %] 
    User: [% user %]           # prints "Tom Thumb"

change_name:

    # create a local 'user' namespace, masking 'Tom Thumb'
    [% user.name = 'Jack Herer' %]

If you find yourself setting global variables from within INCLUDE'd
templates then you might want to use the pre-defined 'global'
namespace.  This is always pre-defined and globally accessible to
every template.

    [% INCLUDE global_change_name %]
    [% global.sysname %]       # prints "Badger"

global_change_name:

    [% global.sysname = 'Badger' %]

Alternately, you might find the PROCESS directive to be more
appropriate.  The PROCESS directive is similar to INCLUDE in all
respects except that it B<does not> perform any localisation of
variables.  Changes made to variables in the sub-template, and indeed
any variable definitions specified in the directive, will affect the
including template.  What you see is what you get.

    [% name = 'foo'
       age  = 100
    %] 
    [% PROCESS change_name  age = 101 %]
    Name is now '[% name %]' and age is [% age %] 

Output:

    Name is 'foo'
    Changing 'foo' to 'bar'
    Name is now 'bar' and age is 101

This is generally useful for processing separate files that define 
various configuration values.  

    [% PROCESS myconfig %]
    <img src="$images/mylogo.gif">

myconfig:

    [% server   = 'www.myserver.com'
       homepage = "http://$server/"
       images   = '/images'
    %]

Output:

    <img src="/images/mylogo.gif">

See also the PRE_PROCESS option which allows you to specify such a file
that will automatically be processed before each template.

In addition to separate files, template blocks can be defined and 
processed with the INCLUDE directive.  These are defined with the BLOCK
directive and are parsed, compiled and cached as for files.

    [% BLOCK tabrow %]
    <tr><td>[% name %]<td><td>[% email %]</td></tr>
    [% END %]
  
    <table>
    [% INCLUDE tabrow  name='Fred'  email='fred@nowhere.com' %]
    [% INCLUDE tabrow  name='Alan'  email='alan@nowhere.com' %]
    </table>

A BLOCK definition may be used before it is defined, as long as the
definition resides in he same file.  The block definition itself does
not generate any output.

    [% INCLUDE tmpblk %]

    [% BLOCK tmpblk %] This is OK [% END %]

Note that both PROCESS and INCLUDE will raise a 'file' exception if an 
attempt is made to recurse into the same template file (e.g. by calling
[% INCLUDE myself %] from within the template 'myself').  The RECURSION
option can be enabled to permit recursion for some special cases.  It is 
assumed that you know what you're doing if you take this step.

=head2 DEFINING MACROS

The MACRO directive allows you to define a directive or directive block
which is then repeatedly evaluated each time the macro is called. 

    [% MACRO header INCLUDE header %]

    [% header %]   # => [% INCLUDE header %]

Macros can be passed named parameters when called.  These values remain 
local to the macro.

    [% header(title='Hello World') %]  
                   # => [% INCLUDE header title='Hello World' %]

A MACRO definition may include parameter names.  Values passed to the 
macros are then mapped to these local variables.  Other named parameters
may follow these.

    [% MACRO header(title) INCLUDE header %]

    [% header('Hello World') %]
    [% header('Hello World', bgcol='#123456') %]

equivalent to:

    [% INCLUDE header title='Hello World' %]
    [% INCLUDE header title='Hello World' bgcol='#123456# %]

A MACRO may preceed any directive and must conform to the structure 
of the directive.

    [% MACRO header IF frames %]
       [% INCLUDE frames/header %]
    [% ELSE %]
       [% INCLUDE header %]
    [% END %]

    [% header %]

A MACRO may also be defined as an anonymous BLOCK.  The block will be 
evaluated each time the macro is called.  A macro must be defined before
it is used.

    [% MACRO header BLOCK %]
       ...content...
    [% END %]

    [% header %]

=head2 PLUGIN OBJECTS AND LIBRARIES

The USE directive can be used to load and initialise "plugin"
extension modules.

    [% USE myplugin %]

A plugin is a regular Perl module that conforms to a particular
object-oriented interface, allowing it to be loaded into and used
automatically by the Template Toolkit.  For details of this interface
and information on writing plugins, consult L<Template::Plugin>. 

The plugin name is case-sensitive and will be appended to the
PLUGIN_BASE value (default: 'Template::Plugin') to construct a full
module name.  Any periods, '.', in the name will be converted to '::'.

    [% USE MyPlugin %]     #  => Template::Plugin::MyPlugin
    [% USE Foo.Bar  %]     #  => Template::Plugin::Foo::Bar

Various 'system' plugins are included with the Template Toolkit (see 
below and L<TEMPLATE TOOLKIT PLUGINS>.  These can be specified in lower
case and are mapped to the appropriate name.

    [% USE cgi   %]        # => Template::Plugin::CGI
    [% USE table %]        # => Template::Plugin::Table

Any additional parameters supplied in parenthesis after the plugin name
will be also be passed to the new() constructor.  A reference to the 
template Context object is always passed as the first parameter.

    [% USE MyPlugin('foo', 123) %]
       ==> Template::Plugin::MyPlugin->new($context, 'foo', 123);

Named parameters may also be specified.  These are collated into a
hash which is passed by reference as the last parameter to the
constructor, as per the general template code calling interface
described earlier.

    [% USE Chat('guestroom', max=50, lines=20, features='none') %]
       ==> Template::Plugin::Chat->new($context, 'guestroom', 
		{ max => 50, lines => 20, features => 'none' } );

The plugin may represent any data type; a simple variable, hash, list or
code reference, but in the general case it will be an object reference.
Methods can be called on the object (or the relevant members of the
specific data type) in the usual way:

    [% USE Chat('guestroom') %]
    Cheezy Chat Room: [% Chat.roomname %]
    [% FOREACH line = Chat.messages %]
       [% line.author %]: [% line.text %]
    [% END %]

An alternative name may be provided for the plugin by which it can be 
referenced:

    [% USE guest = Chat('guestroom') %]
    Cheezy Chat Room: [% guest.roomname %]

You can use this approach to create multiple plugin objects with
different configurations.  This example shows how the 'format' plugin
is used to create sub-routines bound to variables for formatting text
as per printf().

    [% USE bold = format('<b>%s</b>') %]
    [% USE ital = format('<i>%s</i>') %]

    [% bold('This is bold')   %]
    [% ital('This is italic') %]

Output:

    <b>This is bold</b>
    <i>This is italic</i>

The URL plugin allows you to build dynamic URLs from a base part and
optional query parameters.

    [% USE mycgi = URL('/cgi-bin/foo.pl', debug=1) %]
    <a href="[% mycgi %]">...
    <a href="[% mycgi(mode='submit') %]"...

Output:

    <a href="/cgi-bin/foo.pl?debug=1">...
    <a href="/cgi-bin/foo.pl?mode=submit&debug=1">...

The CGI plugin is an example of one which delegates to another Perl
module.  In this this case, it is to Lincoln Stein's CGI.pm module.
All of the methods provided by CGI.pm are available via the plugin.

    [% USE CGI %]

    [% CGI.start_form %]

    [% CGI.checkbox_group(name   =>   'colours', 
                          values => [ 'red' 'green' 'blue' ])
    %]

    [% CGI.popup_menu(name   =>   'items', 
                      values => [ 'foo' 'bar' 'baz' ])
    %]

    [% CGI.end_form %]

Simon Matthews E<lt>sam@knowledgepool.comE<gt> has written a DBI
plugin which provides an interface to Tim Bunce's DBI module (both
available from CPAN).  Here's a short example:

    [% USE DBI('DBI:mSQL:mydbname') %]

    [% FOREACH user = DBI.query('SELECT * FROM users') %]
       [% user.id %] [% user.name %] [% user.etc.etc %]
    [% END %]

See the 'TEMPLATE TOOLKIT PLUGINS' section below for more information
on the plugins distributed with the toolkit or available from CPAN.

The LOAD_PERL option (disabled by default) provides a further way by
which external Perl modules may be loaded.  If a regular Perl module
(i.e. not a Template::Plugin::* or other module relative to some
PLUGIN_BASE) supports an object-oriented interface and a new()
constructor then it can be loaded and wrapped automatically by a
Template::Plugin object.  The following example shows how the IO::File
module might be used.  Please note that this feature is still
experimental.

    [% USE file = IO.File('/tmp/mydata') %]

    [% WHILE line = file.getline %]
       <!-- [% line %] -->
    [% END %]

=head2 EVALUATING PERL CODE

The PERL directive is used to mark the start of a block which contains
Perl code for evaluation.  The EVAL_PERL option must be enabled for Perl
code to be evaluated.  A 'perl' exception will be thrown otherwise.

Perl code is evaluated in the Template::Perl package.  The $context
package variable contains a reference to the current Template::Context
object.  Template output may be generated by the output() method, for 
example.

  [% PERL %]
     $context->output("This output generated by Perl code");
  [% END %]

The $stash variable contains a reference to the top-level stash object
which manages template variables.

  [% PERL %]
     $stash->{'foo'} = 'Bar';
  [% END %]

  Foo is [% foo %]

Output
  Foo is Bar

The block may contain other directives which are evaluated first.  The 
processed block output is then passed to Perl for evaluation.  

  [% PERL %]
     $stash->{'people'} = join(', ', qw( [% foo %] [% bar %] ));
  [% END %]

Any error encountered during the evaluation of the Perl code will be
thrown as a 'perl' exception.

=head2 POST-PROCESSING FILTERS

The FILTER directive can be used to post-process the output of a
block.  The '|' character can also be used as an alias for 'FILTER'.

    [% FILTER html %]
       HTML text may have < and > characters embedded which you
       want converted to the correct HTML entities.  The 'html'
       filter does this for you.
    [% END %]

    [% mytext FILTER html %]

    [% mytext | html %]

The following filters are avilable by default:

=over 4

=item html

Converts the characters '<', '>' and '&' to '&lt;', '&gt;' and '&amp',
respectively, protecting them from being interpreted as representing
HTML tags or entities. 

    [% FILTER html %]
    Binary "<=>" returns -1, 0, or 1 depending on...
    [% END %]

output:

    Binary "&lt;=&gt;" returns -1, 0, or 1 depending on...

=item html_para

This filter formats a block of text into HTML paragraphs.  A sequence of 
two or more newlines is used as the delimiter for paragraphs which are 
then wrapped in HTML E<lt>pE<gt>...E<lt>/pE<gt> tags.

    [% FILTER html_para %]
    The cat sat on the mat.

    Mary had a little lamb.
    [% END %]

output:

    <p>
    The cat sat on the mat.
    </p>

    <p>
    Mary had a little lamb.
    </p>

=item html_break

Similar to the html_para filter described above, but uses the HTML tag
sequence E<lt>brE<gt>E<lt>brE<gt> to join paragraphs.

    [% FILTER html_para %]
    The cat sat on the mat.

    Mary had a little lamb.
    [% END %]

output:

    The cat sat on the mat.
    <br>
    <br>
    Mary had a little lamb.

=item format(format)

The 'format' filter takes a format string as a parameter (as per
printf()) and formats each line of text accordingly.

    [% FILTER format('<!-- %-40s -->') %]
    This is a block of text filtered 
    through the above format.
    [% END %]

output:

    <!-- This is a block of text filtered        -->
    <!-- through the above format.               -->

=item truncate(length)

Truncates the text block to the length specified, or a default length of
32.  Truncated text will be terminated with '...' (i.e. the '...' falls
inside the required length, rather than appending to it).

    [% FILTER truncate(21) %]
    I have much to say on this matter that has previously been said
    on more than one occassion.
    [% END %]

output:

    I have much to say...

=item repeat(iterations)

Repeats the text block for as many iterations as are specified (default: 1).

    [% FILTER repeat(3) %]
    Am I repeating myself?
    [% END %]

output:

    Am I repeating myself?
    Am I repeating myself?
    Am I repeating myself?

=item remove(string) 

Searches the input text for any occurences of the specified string and 
removes them.  A Perl regular expression may be specified as the search 
string.

    [% "The  cat  sat  on  the  mat" FILTER remove('\s+') %]

output: 

    Thecatsatonthemat

=item replace(search, replace) 

Similar to the remove filter described above, but taking a second parameter
which is used as a replacement string for instances of the search string.

    [% "The  cat  sat  on  the  mat" FILTER replace('\s+'m '_') %]

output: 

    The_cat_sat_on_the_mat

=item redirect(file)

The 'redirect' filter redirects the output of the block into a separate
file, specified relative to the OUTPUT_PATH configuration item.

    [% FOREACH user = myorg.userlist %]
       [% FILTER redirect("users/${username}.html") %]
          [% INCLUDE userinfo %]
       [% END %]
    [% END %]

=item into(varname)

The 'into' filter allows you to capture the output of a block into a template 
variable.

    [% FILTER into('user_details') %]
       User: [% user.name %]
       [% INCLUDE userinfo %]
    [% END %]

    [% notify_new_user_details(user_details) %]

=back

Additional filters may be provided via the FILTERS configuration option.
Filters may also be added at any time via the register_filter($name, $factory)
method.  See L<Template::Filters|Template::Filters> for further information.

A filter that is created without any specific parameters will be cached
and re-used whenever that same filter is required.  Specifying parameters
to a filter will always cause a new filter instance to be created.  

    [% FILTER myfilter %]
       # calls 'myfilter' factory code
       Blah Blah Blah
    [% END %]
       
    [% FILTER myfilter %]
       # re-uses cached filter created above
       Cabbages
    [% END %]
  
    [% FILTER myfilter('foo') %]
       # calls 'myfilter' factory code, passing 'foo'
       Rhubarb
    [% END %]

Filters that are created with parameters will not be cached unless an 
alias is provided for them.  The filter instance can then be re-used by
specifying the alias.

    [% FILTER non_atomic = censor('nuclear') %]
       # creates and runs the filter, aliasing it to non_atomic
       ...contentus maximus...
    [% END %]
  
    [% FILTER non_atomic %]
       # re-uses cached non_atomic filter created above
       ...ditto contentus...
    [% END %]

FILTERS may be nested within other filters.  Multiple FILTER definitions
may be added after other (non-block) directives.

    [% FILTER this_way %]
       ...content...
       [% FILTER that_way %]
          ...blah...
       [% END %]
    [% END %]

    [% INCLUDE myfile FILTER myfilter FILTER format('<!-- %s -->') %]

The '|' character can be used as an alias for 'FILTER' to allow a more 
succint way of expressing the above.

    [% INCLUDE myfile | myfilter | format('<!-- %s -->') %]

    [% mytext | html %]


=head2 ERROR HANDLING AND FLOW CONTROL

There are two kinds of error that may occur within the Template
Toolkit.  The first (which we try to avoid) are 'Perl errors' caused
by incorrect usage, or heaven forbid, bugs in the Template Toolkit.
See the BUGS section or the F<TODO> file for more detail on those.
Thankfully, these are comparatively rare and most problems are simply
due to calling a method incorrectly or passing the wrong parameters.

The Template Toolkit doesn't go out of it's way to check every parameter
you pass it.  On the whole, it is fairly tolerant and will leave it up 
to Perl's far superior error checking to report anything seriously untoward
that occurs.

The other kind of errors that concerns us more are those relating to
the template processing "runtime".  These are the (un)expected things
that happen when a template is being processed that we might be
interested in finding out about.  They don't mean that the Template
Toolkit has failed to do what was asked of it, but rather that what
was asked of it didn't make sense, or didn't work as it should.  These
kind of errors might include a variable being used that isn't defined
('undef'), a file that couldn't be found, or properly parsed for an
INCLUDE directive ('file'), a database query that failed in some user
code, a calculation that contains an illegal value, an invalid value
for some verified data, and so on (any error types can be
user-defined).

These kinds of errors are raised as 'exceptions'.  An exception has a
'type' which is a single word describing the kind of error, and an
'info' field containing any additional information.

These exceptions may be caught (i.e. "handled") by an entry defined in
the hash array passed as the CATCH parameter to the Template
constructor.  The keys in the hash represent the error types and the
values should contain a status code (e.g. STATUS_OK, STATUS_STOP) or a
code reference which will be called when exceptions of that type are
thrown.  Such code references are passed three parameters; a reference
to the template "Context" object, the error type and the error info.
Having performed any processing, it should then return a status code
or an exception object to be propagated back to the user.  Returning a
value of 0 (STATUS_OK) indicates that the exception has been
successfully handled and processing should continue as before.
Note that you need to specify C<:status> as a parameter to 
C<use Template> in order for the STATUS_* constants to be defined.

    use Template qw( :status );

    my $tproc = Template->new({	
  	CATCH => {
  	  'undef' => STATUS_OK,
  	  'file'  => sub {
  			my ($context, $type, $info) = @_;
  			$context->output("<!-- $type: ($info) -->");
  			return STATUS_OK;
  		     },
  	},
    });

A template block may also be defined that will be processed when
certain exception types are raised.  The CATCH directive starts the
block definition and should contain a single word denoting the error
type.  The variable 'e' will be defined in a catch block representing
the error.  The 'type' and 'info' members represent the appropriate
values.

    [% CATCH file %]
      <!-- file error: [% e.info %] -->
    [% END %]

A CATCH block defined without an error type will become a default
handler.  This will be processed when an exception is raised that has
no specific handler of its own defined.

    [% CATCH %]
      An error ([% e.type %]) occurred: 
        [% e.info %]
    [% END %]

A default handler can be installed via the CATCH option by defining
the error type as 'default'.

    my $tproc = Template->new({	
        CATCH => {
            'default' => STATUS_OK,
        },
    });

As from version 1.00, exception types may also be dotted values, e.g. 
'foo.bar'.  If a specific handler does not exist for the exception type, 
then elements of the name are progressively stripped from the end until 
a handler is found that represents the remaining part.  An exception type
'foo.bar' could thus be handled by a 'foo.bar' or 'foo' handler.  The 
'default' handler will be used, if it exists, as a last resort.

Any user-defined exception types can be created, returned, thrown and caught 
at will.  User code may return an exception as the status code to indicate
an error.  This exception type can then be caught in the usual way.

    $tproc->process('myexample', { 'go_mad' => \&go_mad })
      || die $tproc->error();
  
    sub go_mad {
  	return (undef, Template::Exception->new('mad', 
                                                'Big Fat Error'));
    }

Example:

    [% CATCH mad %]
    Gone mad: [% e.info %]
    [% END %]

    Going insane...
    [% go_mad %]

Output:

    Going insane...
    Gone mad: Big Fat Error

A CATCH block will be installed at the point in the template at which
it is defined and remains available thereafter for the lifetime of the
template processor or until redefined.  This is probably a bug and may
soon be 'fixed' so that handlers defined in templates only persist
until the parent process() method ends.

An exception that is not caught, or one that is caught by a handler that 
then propagates the exception onward, will cause the Template process()
method to stop and return a false status (failed).  A string representing
the exception that occurred (in the format "$type: $info") can be returned
by calling the error() method. 

    $tproc->process('myexample')
        || die "PROCESSING ERROR: ", $tproc->error(), "\n";

You can 'throw' an exception using the THROW directive, specifying the 
error type (unquoted) and value to represent the information.

    [% THROW up 'Feeling Sick' %]

Output:

    PROCESSING ERROR: up: Feeling Sick

The STOP directive can be used to indicate that the processor should
stop gracefully without processing any more of the template document.
This is known as a 'planned stop' and the Template process() method
will return a B<true> value.  This indicates I<'the template was
processed successfully according to the directives within it'> which
hopefully, it was.  If you need to find out if the template ended
'naturally' or via a STOP (or RETURN, as discussed below) directive,
you can call the Template error() method which will return the
numerical value returned from the last directive, represented by the
constants STATUS_OK, STATUS_STOP, STATUS_RETURN, etc.  If the previous
process() did not return a true value then the error() method returns
a string representing the exception that occurred.

The STOP directive can be used in conjunction with CATCH blocks to safely
trap and report any fatal errors and then end the template process gracefully.

    [% CATCH fatal_db_error %]
       <p>
       <b>A fatal database error has occurred</b>
       <br>
       Error: [% e.info %]
       <br>
       We apologise for the inconvenience.  The cleaning lady 
       has removed the server power to plug in her vacuum cleaner.
       Please try again later.
       </p>
       [% ERROR "[$e.type] $e.info" %]
       [% INCLUDE footer %]
       [% STOP %]
    [% END %]

The ERROR directive as used in the above example, sends the specified 
value to the current output stream for the template processor.  By 
default, this is STDERR.

The RETURN directive is similar to STOP except that it terminates the
current template file only.  If the file in which the RETURN directive
exists has been INCLUDE'd by another, then processing will continue at
the point immediately after the INCLUDE directive.

    Before
    [% INCLUDE half_wit %]
    After
  
    [% BLOCK half_wit %]
    This is just half...
    [% RETURN %]
    ...a complete block
    [% END %]

Output:

    Before
    This is just half...
    After

The STOP, RETURN, THROW and ERROR directives can all be used in conjunction
with other 'side-effect' directives.  e.g.

    [% THROW up 'Contents of stomach' IF drunk %]
    [% STOP IF brain_exploded %]
    [% RETURN IF no_input %]
    [% ERROR 'Stupid, stupid, user' IF easy2guess(passwd) %]
    [% THROW badpasswd "$user.id has a dumb password ($user.passwd)"
  	 FOREACH user = naughty_user_list
    %]



