Contents
Top- Template Style and Parsing Options
- START_TAG, END_TAG
- TAG_STYLE
- PRE_CHOMP, POST_CHOMP
- TRIM
- INTERPOLATE
- ANYCASE
- Template Files and Blocks
- INCLUDE_PATH
- DELIMITER
- ABSOLUTE
- RELATIVE
- DEFAULT
- BLOCKS
- AUTO_RESET
- RECURSION
- Template Variables
- VARIABLES
- CONSTANTS
- CONSTANT_NAMESPACE
- NAMESPACE
- Template Processing Options
- PRE_PROCESS, POST_PROCESS
- PROCESS
- WRAPPER
- ERROR
- Template Runtime Options
- EVAL_PERL
- OUTPUT
- OUTPUT_PATH
- DEBUG
- DEBUG_FORMAT
- Caching and Compiling Options
- CACHE_SIZE
- STAT_TTL
- COMPILE_EXT
- COMPILE_DIR
- Plugins and Filters
- PLUGINS
- PLUGIN_BASE
- LOAD_PERL
- FILTERS
- Customisation and Extension
- LOAD_TEMPLATES
- LOAD_PLUGINS
- LOAD_FILTERS
- TOLERANT
- SERVICE
- CONTEXT
- STASH
- PARSER
- GRAMMAR
Template Style and Parsing Options
TopSTART_TAG, END_TAG
Top
The START_TAG and END_TAG options are used to
specify character sequences or regular expressions that mark the start
and end of a template directive. The default values for
START_TAG and END_TAG are '[%' and
'%]' respectively, giving us the familiar directive style:
[% example %]
Any Perl regex characters can be used and therefore should be escaped (or
use the Perl quotemeta function) if they are intended to
represent literal characters.
my $template = Template->new({
START_TAG => quotemeta('<+'),
END_TAG => quotemeta('+>'),
});
Example:
<+ INCLUDE foobar +>
The TAGS directive can also be used to set the
START_TAG and END_TAG values on a per-template
file basis.
[% TAGS <+ +> %]
TAG_STYLE
Top
The TAG_STYLE option can be used to set both
START_TAG and END_TAG according to pre-defined
tag styles.
my $template = Template->new({
TAG_STYLE => 'star',
});
Available styles are:
template [% ... %] (default) template1 [% ... %] or %% ... %% (TT version 1) metatext %% ... %% (Text::MetaText) star [* ... *] (TT alternate) php <? ... ?> (PHP) asp <% ... %> (ASP) mason <% ... > (HTML::Mason) html <!-- ... --> (HTML comments)
Any values specified for START_TAG and/or
END_TAG will override those defined by a
TAG_STYLE.
The TAGS directive may also be used to set a
TAG_STYLE
[% TAGS html %] <!-- INCLUDE header -->
PRE_CHOMP, POST_CHOMP
TopAnything outside a directive tag is considered plain text and is generally passed through unaltered (but see the INTERPOLATE option). This includes all whitespace and newlines characters surrounding directive tags. Directives that don't generate any output will leave gaps in the output document.
Example:
Foo [% a = 10 %] Bar
Output:
Foo Bar
The PRE_CHOMP and POST_CHOMP options can help
to clean up some of this extraneous whitespace. Both are disabled by
default.
my $template = Template-E<gt>new({
PRE_CHOMP =E<gt> 1,
POST_CHOMP =E<gt> 1,
});
With PRE_CHOMP set to 1, the newline and
whitespace preceding a directive at the start of a line will be deleted.
This has the effect of concatenating a line that starts with a directive
onto the end of the previous line.
Foo <----------.
|
,---(PRE_CHOMP)----'
|
`-- [% a = 10 %] --.
|
,---(POST_CHOMP)---'
|
`-> Bar
With POST_CHOMP set to 1, any whitespace after
a directive up to and including the newline will be deleted. This has the
effect of joining a line that ends with a directive onto the start of the
next line.
If PRE_CHOMP or POST_CHOMP is set to
2, all whitespace including any number of newline will be
removed and replaced with a single space. This is useful for HTML, where
(usually) a contiguous block of whitespace is rendered the same as a
single space.
With PRE_CHOMP or POST_CHOMP set to
3, all adjacent whitespace (including newlines) will be
removed entirely.
These values are defined as CHOMP_NONE,
CHOMP_ONE, CHOMP_COLLAPSE and
CHOMP_GREEDY constants in the Template::Constants module.
CHOMP_ALL is also defined as an alias for
CHOMP_ONE to provide backwards compatability with earlier
version of the Template Toolkit.
Additionally the chomp tag modifiers listed below may also be used for
the PRE_CHOMP and POST_CHOMP configuration.
my $template = Template->new({
PRE_CHOMP => '~',
POST_CHOMP => '-',
});
PRE_CHOMP and POST_CHOMP can be activated for
individual directives by placing a '-' immediately at the
start and/or end of the directive.
[% FOREACH user IN userlist %] [%- user -%] [% END %]
This has the same effect as CHOMP_ONE in removing all
whitespace before or after the directive up to and including the newline.
The template will be processed as if written:
[% FOREACH user IN userlist %][% user %][% END %]
To remove all whitespace including any number of newlines, use the
'~' character instead.
[% FOREACH user IN userlist %] [%~ user ~%] [% END %]
To collapse all whitespace to a single space, use the '='
character.
[% FOREACH user IN userlist %] [%= user =%] [% END %]
Here the template is processed as if written:
[% FOREACH user IN userlist %] [% user %] [% END %]
If you have PRE_CHOMP or POST_CHOMP set as
configuration options then you can use '+' to disable any
chomping options (i.e. leave the whitespace intact) on a per-directive
basis.
[% FOREACH user = userlist %] User: [% user +%] [% END %]
With POST_CHOMP set to CHOMP_ONE, the above
example would be parsed as if written:
[% FOREACH user = userlist %]User: [% user %] [% END %]
For reference, the PRE_CHOMP and POST_CHOMP
configuration options may be set to any of the following:
Constant Value Tag Modifier ---------------------------------- CHOMP_NONE 0 + CHOMP_ONE 1 - CHOMP_COLLAPSE 2 = CHOMP_GREEDY 3 ~
TRIM
Top
The TRIM option can be set to have any leading and trailing
whitespace automatically removed from the output of all template files
and BLOCKs.
By example, the following BLOCK definition
[% BLOCK foo %] Line 1 of foo [% END %]
will be processed is as "\nLine 1 of foo\n". When
INCLUDEd, the surrounding newlines will also be introduced.
before [% INCLUDE foo %] after
Generated output:
before Line 1 of foo after
With the TRIM option set to any true value, the leading and
trailing newlines (which count as whitespace) will be removed from the
output of the BLOCK.
before Line 1 of foo after
The TRIM option is disabled (0) by default.
INTERPOLATE
Top
The INTERPOLATE flag, when set to any true value will cause
variable references in plain text (i.e. not surrounded by
START_TAG and END_TAG) to be recognised and
interpolated accordingly.
my $template = Template->new({
INTERPOLATE => 1,
});
Variables should be prefixed by a '$' to identify them.
Curly braces can be used in the familiar Perl/shell style to explicitly
scope the variable name where required.
# INTERPOLATE => 0 <a href="http://[% server %]/[% help %]"> <img src="[% images %]/help.gif"></a> [% myorg.name %]
# INTERPOLATE => 1
<a href="http://$server/$help">
<img src="$images/help.gif"></a>
$myorg.name
# explicit scoping with { }
<img src="$images/${icon.next}.gif">
Note that a limitation in Perl's regex engine restricts the maximum
length of an interpolated template to around 32 kilobytes or possibly
less. Files that exceed this limit in size will typically cause Perl to
dump core with a segmentation fault. If you routinely process templates
of this size then you should disable INTERPOLATE or split
the templates in several smaller files or blocks which can then be joined
backed together via PROCESS or INCLUDE.
ANYCASE
Top
By default, directive keywords should be expressed in UPPER CASE. The
ANYCASE option can be set to allow directive keywords to be
specified in any case.
# ANYCASE => 0 (default) [% INCLUDE foobar %] # OK [% include foobar %] # ERROR [% include = 10 %] # OK, 'include' is a variable
# ANYCASE => 1 [% INCLUDE foobar %] # OK [% include foobar %] # OK [% include = 10 %] # ERROR, 'include' is reserved word
One side-effect of enabling ANYCASE is that you cannot use a
variable of the same name as a reserved word, regardless of case. The
reserved words are currently:
GET CALL SET DEFAULT INSERT INCLUDE PROCESS WRAPPER IF UNLESS ELSE ELSIF FOR FOREACH WHILE SWITCH CASE USE PLUGIN FILTER MACRO PERL RAWPERL BLOCK META TRY THROW CATCH FINAL NEXT LAST BREAK RETURN STOP CLEAR TO STEP AND OR NOT MOD DIV END
The only lower case reserved words that cannot be used for variables,
regardless of the ANYCASE option, are the operators:
and or not mod div
Template Files and Blocks
TopINCLUDE_PATH
Top
The INCLUDE_PATH is used to specify one or more directories
in which template files are located. When a template is requested that
isn't defined locally as a BLOCK, each of the
INCLUDE_PATH directories is searched in turn to locate the
template file. Multiple directories can be specified as a reference to a
list or as a single string where each directory is delimited by
':'.
my $template = Template->new({
INCLUDE_PATH => '/usr/local/templates',
});
my $template = Template->new({
INCLUDE_PATH => '/usr/local/templates:/tmp/my/templates',
});
my $template = Template->new({
INCLUDE_PATH => [ '/usr/local/templates',
'/tmp/my/templates' ],
});
On Win32 systems, a little extra magic is invoked, ignoring delimiters
that have ':' followed by a '/' or
'\'. This avoids confusion when using directory names like
'C:\Blah Blah'.
When specified as a list, the INCLUDE_PATH path can contain
elements which dynamically generate a list of INCLUDE_PATH
directories. These generator elements can be specified as a reference to
a subroutine or an object which implements a paths() method.
my $template = Template->new({
INCLUDE_PATH => [ '/usr/local/templates',
\&incpath_generator,
My::IncPath::Generator->new( ... ) ],
});
Each time a template is requested and the INCLUDE_PATH
examined, the subroutine or object method will be called. A reference to
a list of directories should be returned. Generator subroutines should
report errors using die(). Generator objects should return
undef and make an error available via its error() method.
For example:
sub incpath_generator {
# ...some code...
if ($all_is_well) {
return \@list_of_directories;
}
else {
die "cannot generate INCLUDE_PATH...\n";
}
}
or:
package My::IncPath::Generator;
# Template::Base (or Class::Base) provides error() method
use Template::Base;
use base qw( Template::Base );
sub paths {
my $self = shift;
# ...some code...
if ($all_is_well) {
return \@list_of_directories;
}
else {
return $self->error("cannot generate INCLUDE_PATH...\n");
}
}
1;
DELIMITER
Top
Used to provide an alternative delimiter character sequence for
separating paths specified in the INCLUDE_PATH. The default
value for DELIMITER is ':'.
my $template = Template->new({
DELIMITER => '; ',
INCLUDE_PATH => 'C:/HERE/NOW; D:/THERE/THEN',
});
On Win32 systems, the default delimiter is a little more intelligent,
splitting paths only on ':' characters that aren't followed
by a '/'. This means that the following should work as
planned, splitting the INCLUDE_PATH into 2 separate
directories, C:/foo and C:/bar.
# on Win32 only
my $template = Template->new({
INCLUDE_PATH => 'C:/Foo:C:/Bar'
});
However, if you're using Win32 then it's recommended that you explicitly
set the DELIMITER character to something else (e.g.
';') rather than rely on this subtle magic.
ABSOLUTE
Top
The ABSOLUTE flag is used to indicate if templates specified
with absolute filenames (e.g. '/foo/bar') should be
processed. It is disabled by default and any attempt to load a template
by such a name will cause a 'file' exception to be raised.
my $template = Template->new({
ABSOLUTE => 1,
});
# this is why it's disabled by default
[% INSERT /etc/passwd %]
On Win32 systems, the regular expression for matching absolute pathnames is tweaked slightly to also detect filenames that start with a driver letter and colon, such as:
C:/Foo/Bar
RELATIVE
Top
The RELATIVE flag is used to indicate if templates specified
with filenames relative to the current directory (e.g.
'./foo/bar' or '../../some/where/else') should
be loaded. It is also disabled by default, and will raise a
'file' error if such template names are encountered.
my $template = Template->new({
RELATIVE => 1,
});
[% INCLUDE ../logs/error.log %]
DEFAULT
Top
The DEFAULT option can be used to specify a default template
which should be used whenever a specified template can't be found in the
INCLUDE_PATH.
my $template = Template->new({
DEFAULT => 'notfound.html',
});
If a non-existant template is requested through the Template Template#process() method, or by an
INCLUDE, PROCESS or WRAPPER
directive, then the DEFAULT template will instead be
processed, if defined. Note that the DEFAULT template is not
used when templates are specified with absolute or relative filenames, or
as a reference to a input file handle or text string.
BLOCKS
Top
The BLOCKS option can be used to pre-define a default set of
template blocks. These should be specified as a reference to a hash array
mapping template names to template text, subroutines or Template::Document objects.
my $template = Template->new({
BLOCKS => {
header => 'The Header. [% title %]',
footer => sub { return $some_output_text },
another => Template::Document->new({ ... }),
},
});
AUTO_RESET
Top
The AUTO_RESET option is set by default and causes the local
BLOCKS cache for the Template::Context object to be
reset on each call to the Template Template#process() method. This ensures that
any BLOCKs defined within a template will only persist until
that template is finished processing. This prevents BLOCKs
defined in one processing request from interfering with other independent
requests subsequently processed by the same context object.
The BLOCKS item may be used to specify a default set of
block definitions for the Template::Context object. Subsequent BLOCK
definitions in templates will over-ride these but they will be reinstated
on each reset if AUTO_RESET is enabled (default), or if the
Template::Context Template::Context#reset() method is called.
RECURSION
TopThe template processor will raise a file exception if it detects direct or indirect recursion into a template. Setting this option to any true value will allow templates to include each other recursively.
Template Variables
TopVARIABLES
Top
The VARIABLES option (or PRE_DEFINE - they're
equivalent) can be used to specify a hash array of template variables
that should be used to pre-initialise the stash when it is created. These
items are ignored if the STASH item is defined.
my $template = Template->new({
VARIABLES => {
title => 'A Demo Page',
author => 'Joe Random Hacker',
version => 3.14,
},
};
or
my $template = Template->new({
PRE_DEFINE => {
title => 'A Demo Page',
author => 'Joe Random Hacker',
version => 3.14,
},
};
CONSTANTS
Top
The CONSTANTS option can be used to specify a hash array of
template variables that are compile-time constants. These variables are
resolved once when the template is compiled, and thus don't require
further resolution at runtime. This results in significantly faster
processing of the compiled templates and can be used for variables that
don't change from one request to the next.
my $template = Template->new({
CONSTANTS => {
title => 'A Demo Page',
author => 'Joe Random Hacker',
version => 3.14,
},
};
CONSTANT_NAMESPACE
Top
Constant variables are accessed via the constants namespace
by default.
[% constants.title %]
The CONSTANTS_NAMESPACE option can be set to specify an
alternate namespace.
my $template = Template->new({
CONSTANTS => {
title => 'A Demo Page',
# ...etc...
},
CONSTANTS_NAMESPACE => 'const',
};
In this case the constants would then be accessed as:
[% const.title %]
NAMESPACE
TopThe constant folding mechanism described above is an example of a namespace handler. Namespace handlers can be defined to provide alternate parsing mechanisms for variables in different namespaces.
Under the hood, the Template module converts a constructor configuration such as:
my $template = Template->new({
CONSTANTS => {
title => 'A Demo Page',
# ...etc...
},
CONSTANTS_NAMESPACE => 'const',
};
into one like:
my $template = Template->new({
NAMESPACE => {
const => Template:::Namespace::Constants->new({
title => 'A Demo Page',
# ...etc...
}),
},
};
You can use this mechanism to define multiple constant namespaces, or to install custom handlers of your own.
my $template = Template->new({
NAMESPACE => {
site => Template:::Namespace::Constants->new({
title => "Wardley's Widgets",
version => 2.718,
}),
author => Template:::Namespace::Constants->new({
name => 'Andy Wardley',
email => 'abw@andywardley.com',
}),
voodoo => My::Namespace::Handler->new( ... ),
},
};
Now you have two constant namespaces, for example:
[% site.title %] [% author.name %]
as well as your own custom namespace handler installed for the 'voodoo' namespace.
[% voodoo.magic %]
See Template::Namespace::Constants for an example of what a namespace handler looks like on the inside.
Template Processing Options
TopThe following options are used to specify any additional templates that should be processed before, after, around or instead of the template passed as the first argument to the Template Template#process() method. These options can be perform various useful tasks such as adding standard headers or footers to all pages, wrapping page output in other templates, pre-defining variables or performing initialisation or cleanup tasks, automatically generating page summary information, navigation elements, and so on.
The task of processing the template is delegated internally to the Template::Service
module which, unsurprisingly, also has a Template::Service#process() method. Any
templates defined by the PRE_PROCESS option are processed
first and any output generated is added to the output buffer. Then the
main template is processed, or if one or more PROCESS
templates are defined then they are instead processed in turn. In this
case, one of the PROCESS templates is responsible for
processing the main template, by a directive such as:
[% PROCESS $template %]
The output of processing the main template or the PROCESS
template(s) is then wrapped in any WRAPPER templates, if
defined. WRAPPER templates don't need to worry about
explicitly processing the template because it will have been done for
them already. Instead WRAPPER templates access the content
they are wrapping via the content variable.
wrapper before [% content %] wrapper after
This output generated from processing the main template, and/or any
PROCESS or WRAPPER templates is added to the
output buffer. Finally, any POST_PROCESS templates are
processed and their output is also added to the output buffer which is
then returned.
If the main template throws an exception during processing then any
relevant template(s) defined via the ERROR option will be
processed instead. If defined and successfully processed, the output from
the error template will be added to the output buffer in place of the
template that generated the error and processing will continue, applying
any WRAPPER and POST_PROCESS templates. If no
relevant ERROR option is defined, or if the error occurs in
one of the PRE_PROCESS, WRAPPER or
POST_PROCESS templates, then the process will terminate
immediately and the error will be returned.
PRE_PROCESS, POST_PROCESS
Top
These values may be set to contain the name(s) of template files
(relative to INCLUDE_PATH) which should be processed
immediately before and/or after each template. These do not get added to
templates processed into a document via directives such as
INCLUDE, PROCESS, WRAPPER etc.
my $template = Template->new({
PRE_PROCESS => 'header',
POST_PROCESS => 'footer',
};
Multiple templates may be specified as a reference to a list. Each is processed in the order defined.
my $template = Template->new({
PRE_PROCESS => [ 'config', 'header' ],
POST_PROCESS => 'footer',
};
Alternately, multiple template may be specified as a single string,
delimited by ':'. This delimiter string can be changed via
the DELIMITER option.
my $template = Template->new({
PRE_PROCESS => 'config:header',
POST_PROCESS => 'footer',
};
The PRE_PROCESS and POST_PROCESS templates are
evaluated in the same variable context as the main document and may
define or update variables for subsequent use.
config:
[% # set some site-wide variables bgcolor = '#ffffff' version = 2.718 %]
header:
[% DEFAULT title = 'My Funky Web Site' %]
<html>
<head>
<title>[% title %]</title>
</head>
<body bgcolor="[% bgcolor %]">
footer:
<hr>
Version [% version %]
</body>
</html>
The Template::Document object representing the main template being
processed is available within PRE_PROCESS and
POST_PROCESS templates as the template
variable. Metadata items defined via the META directive may
be accessed accordingly.
$template->process('mydoc.html', $vars);
mydoc.html:
[% META title = 'My Document Title' %] blah blah blah ...
header:
<html>
<head>
<title>[% template.title %]</title>
</head>
<body bgcolor="[% bgcolor %]">
PROCESS
Top
The PROCESS option may be set to contain the name(s) of
template files (relative to INCLUDE_PATH) which should be
processed instead of the main template passed to the Template Template#process() method. This can be used to
apply consistent wrappers around all templates, similar to the use of
PRE_PROCESS and POST_PROCESS templates.
my $template = Template->new({
PROCESS => 'content',
};
# processes 'content' instead of 'foo.html'
$template->process('foo.html');
A reference to the original template is available in the
template variable. Metadata items can be inspected and the
template can be processed by specifying it as a variable reference (i.e.
prefixed by $) to an INCLUDE,
PROCESS or WRAPPER directive.
content:
<html>
<head>
<title>[% template.title %]</title>
</head>
<body>
<!-- begin content -->
[% PROCESS $template %]
<!-- end content -->
<hr>
© Copyright [% template.copyright %]
</body>
</html>
foo.html:
[% META title = 'The Foo Page' author = 'Fred Foo' copyright = '2000 Fred Foo' %] <h1>[% template.title %]</h1> Welcome to the Foo Page, blah blah blah
output:
<html>
<head>
<title>The Foo Page</title>
</head>
<body>
<!-- begin content -->
<h1>The Foo Page</h1>
Welcome to the Foo Page, blah blah blah
<!-- end content -->
<hr>
© Copyright 2000 Fred Foo
</body>
</html>
WRAPPER
Top
The WRAPPER option can be used to specify one or more
templates which should be used to wrap around the output of the main page
template. The main template is processed first (or any
PROCESS template(s)) and the output generated is then passed
as the content variable to the WRAPPER
template(s) as they are processed.
my $template = Template->new({
WRAPPER => 'wrapper',
};
# process 'foo' then wrap in 'wrapper'
$template->process('foo', { message => 'Hello World!' });
wrapper:
<wrapper> [% content %] </wrapper>
foo:
This is the foo file! Message: [% message %]
The output generated from this example is:
<wrapper> This is the foo file! Message: Hello World! </wrapper>
You can specify more than one WRAPPER template by setting
the value to be a reference to a list of templates. The
WRAPPER templates will be processed in reverse order with
the output of each being passed to the next (or previous, depending on
how you look at it) as the 'content' variable. It sounds complicated, but
the end result is that it just "Does The Right Thing" to make wrapper
templates nest in the order you specify.
my $template = Template->new({
WRAPPER => [ 'outer', 'inner' ],
};
# process 'foo' then wrap in 'inner', then in 'outer'
$template->process('foo', { message => 'Hello World!' });
outer:
<outer> [% content %] </outer>
inner:
<inner> [% content %] </inner>
The output generated is then:
<outer> <inner> This is the foo file! Message: Hello World! </inner> </outer>
One side-effect of the "inside-out" processing of the
WRAPPER configuration item (and also the
WRAPPER directive) is that any variables set in the template
being wrapped will be visible to the template doing the wrapping, but not
the other way around.
You can use this to good effect in allowing page templates to set pre-defined values which are then used in the wrapper templates. For example, our main page template 'foo' might look like this:
foo:
[% page = {
title = 'Foo Page'
subtitle = 'Everything There is to Know About Foo'
author = 'Frank Oliver Octagon'
}
%]
<p>
Welcome to the page that tells you everything about foo
blah blah blah...
</p>
The foo template is processed before the wrapper template
meaning that the page data structure will be defined for use
in the wrapper template.
wrapper:
<html>
<head>
<title>[% page.title %]</title>
</head>
<body>
<h1>[% page.title %]</h1>
<h2>[% page.subtitle %]</h1>
<h3>by [% page.author %]</h3>
[% content %]
</body>
</html>
It achieves the same effect as defining META items which are
then accessed via the template variable (which you are still
free to use within WRAPPER templates), but gives you more
flexibility in the type and complexity of data that you can define.
ERROR
Top
The ERROR (or ERRORS if you prefer)
configuration item can be used to name a single template or specify a
hash array mapping exception types to templates which should be used for
error handling. If an uncaught exception is raised from within a template
then the appropriate error template will instead be processed.
If specified as a single value then that template will be processed for all uncaught exceptions.
my $template = Template->new({
ERROR => 'error.html'
});
If the ERROR item is a hash reference the keys are assumed
to be exception types and the relevant template for a givePROCESS
templates are defined then they are instead processed in turn. In this
case, one of the PROCESS templates is responsible for
processing the main template, by a directive such as:
[% PROCESS $template %]
The output of processing the main template or the PROCESS
template(s) is then wrapped in any WRAPPER templates, if
defined. WRAPPER templates don't need to worry about
explicitly processing the template because it will have been done for
them already. Instead WRAPPER templates access the content
they are wrapping via the content variable.
wrapper before [% content %] wrapper after
This output generated from processing the main template, and/or any
PROCESS or WRAPPER templates is added to the
output buffer. Finally, any POST_PROCESS templates are
processed and their output is also added to the output buffer which is
then returned.
If the main template throws an exception during processing then any
relevant template(s) defined via the ERROR option will be
processed instead. If defined and successfully processed, the output from
the error template will be added to the output buffer in place of the
template that generated the error and processing will continue, applying
any WRAPPER and POST_PROCESS templates. If no
relevant ERROR option is defined, or if the error occurs in
one of the PRE_PROCESS, WRAPPER or
POST_PROCESS templates, then the process will terminate
immediately and the error will be returned.
PRE_PROCESS, POST_PROCESS
Top
These values may be set to contain the name(s) of template files
(relative to INCLUDE_PATH) which should be processed
immediately before and/or after each template. These do not get added to
templates processed into a document via directives such as
INCLUDE, PROCESS, WRAPPER etc.
my $template = Template->new({
PRE_PROCESS => 'header',
POST_PROCESS => 'footer',
};
Multiple templates may be specified as a reference to a list. Each is processed in the order defined.
my $template = Template->new({
PRE_PROCESS => [ 'config', 'header' ],
POST_PROCESS => 'footer',
};
Alternately, multiple template may be specified as a single string,
delimited by ':'. This delimiter string can be changed via
the DELIMITER option.
my $template = Template->new({
PRE_PROCESS => 'config:header',
POST_PROCESS => 'footer',
};
The PRE_PROCESS and POST_PROCESS templates are
evaluated in the same variable context as the main document and may
define or update variables for subsequent use.
config:
[% # set some site-wide variables bgcolor = '#ffffff' version = 2.718 %]
header:
[% DEFAULT title = 'My Funky Web Site' %]
<html>
<head>
<title>[% title %]</title>
</head>
<body bgcolor="[% bgcolor %]">
footer:
<hr>
Version [% version %]
</body>
</html>
The Template::Document object representing the main template being
processed is available within PRE_PROCESS and
POST_PROCESS templates as the template
variable. Metadata items defined via the META directive may
be accessed accordingly.
$template->process('mydoc.html', $vars);
mydoc.html:
[% META title = 'My Document Title' %] blah blah blah ...
header:
<html>
<head>
<title>[% template.title %]</title>
</head>
<body bgcolor="[% bgcolor %]">
PROCESS
Top
The PROCESS option may be set to contain the name(s) of
template files (relative to INCLUDE_PATH) which should be
processed instead of the main template passed to the Template Template#process() method. This can be used to
apply consistent wrappers around all templates, similar to the use of
PRE_PROCESS and POST_PROCESS templates.
my $template = Template->new({
PROCESS => 'content',
};
# processes 'content' instead of 'foo.html'
$template->process('foo.html');
A reference to the original template is available in the
template variable. Metadata items can be inspected and the
template can be processed by specifying it as a variable reference (i.e.
prefixed by $) to an INCLUDE,
PROCESS or WRAPPER directive.
content:
<html>
<head>
<title>[% template.title %]</title>
</head>
<body>
<!-- begin content -->
[% PROCESS $template %]
<!-- end content -->
<hr>
© Copyright [% template.copyright %]
</body>
</html>
foo.html:
[% META title = 'The Foo Page' author = 'Fred Foo' copyright = '2000 Fred Foo' %] <h1>[% template.title %]</h1> Welcome to the Foo Page, blah blah blah
output:
<html>
<head>
<title>The Foo Page</title>
</head>
<body>
<!-- begin content -->
<h1>The Foo Page</h1>
Welcome to the Foo Page, blah blah blah
<!-- end content -->
<hr>
© Copyright 2000 Fred Foo
</body>
</html>
WRAPPER
Top
The WRAPPER option can be used to specify one or more
templates which should be used to wrap around the output of the main page
template. The main template is processed first (or any
PROCESS template(s)) and the output generated is then passed
as the content variable to the WRAPPER
template(s) as they are processed.
my $template = Template->new({
WRAPPER => 'wrapper',
};
# process 'foo' then wrap in 'wrapper'
$template->process('foo', { message => 'Hello World!' });
wrapper:
<wrapper> [% content %] </wrapper>
foo:
This is the foo file! Message: [% message %]
The output generated from this example is:
<wrapper> This is the foo file! Message: Hello World! </wrapper>
You can specify more than one WRAPPER template by setting
the value to be a reference to a list of templates. The
WRAPPER templates will be processed in reverse order with
the output of each being passed to the next (or previous, depending on
how you look at it) as the 'content' variable. It sounds complicated, but
the end result is that it just "Does The Right Thing" to make wrapper
templates nest in the order you specify.
my $template = Template->new({
WRAPPER => [ 'outer', 'inner' ],
};
# process 'foo' then wrap in 'inner', then in 'outer'
$template->process('foo', { message => 'Hello World!' });
outer:
<outer> [% content %] </outer>
inner:
<inner> [% content %] </inner>
The output generated is then:
<outer> <inner> This is the foo file! Message: Hello World! </inner> </outer>
One side-effect of the "inside-out" processing of the
WRAPPER configuration item (and also the
WRAPPER directive) is that any variables set in the template
being wrapped will be visible to the template doing the wrapping, but not
the other way around.
You can use this to good effect in allowing page templates to set pre-defined values which are then used in the wrapper templates. For example, our main page template 'foo' might look like this:
foo:
[% page = {
title = 'Foo Page'
subtitle = 'Everything There is to Know About Foo'
author = 'Frank Oliver Octagon'
}
%]
<p>
Welcome to the page that tells you everything about foo
blah blah blah...
</p>
The foo template is processed before the wrapper template
meaning that the page data structure will be defined for use
in the wrapper template.
wrapper:
<html>
<head>
<title>[% page.title %]</title>
</head>
<body>
<h1>[% page.title %]</h1>
<h2>[% page.subtitle %]</h1>
<h3>by [% page.author %]</h3>
[% content %]
</body>
</html>
It achieves the same effect as defining META items which are
then accessed via the template variable (which you are still
free to use within WRAPPER templates), but gives you more
flexibility in the type and complexity of data that you can define.
ERROR
Top
The ERROR (or ERRORS if you prefer)
configuration item can be used to name a single template or specify a
hash array mapping exception types to templates which should be used for
error handling. If an uncaught exception is raised from within a template
then the appropriate error template will instead be processed.
If specified as a single value then that template will be processed for all uncaught exceptions.
my $template = Template->new({
ERROR => 'error.html'
});
If the ERROR item is a hash reference the keys are assumed
to be exception types and the relevant template for a givePROCESS
templates are defined then they are instead processed in turn. In this
case, one of the PROCESS templates is responsible for
processing the main template, by a directive such as:
[% PROCESS $template %]
The output of processing the main template or the PROCESS
template(s) is then wrapped in any WRAPPER templates, if
defined. WRAPPER templates don't need to worry about
explicitly processing the template because it will have been done for
them already. Instead WRAPPER templates access the content
they are wrapping via the content variable.
wrapper before [% content %] wrapper after
This output generated from processing the main template, and/or any
PROCESS or WRAPPER templates is added to the
output buffer. Finally, any POST_PROCESS templates are
processed and their output is also added to the output buffer which is
then returned.
If the main template throws an exception during processing then any
relevant template(s) defined via the ERROR option will be
processed instead. If defined and successfully processed, the output from
the error template will be added to the output buffer in place of the
template that generated the error and processing will continue, applying
any WRAPPER and POST_PROCESS templates. If no
relevant ERROR option is defined, or if the error occurs in
one of the PRE_PROCESS, WRAPPER or
POST_PROCESS templates, then the process will terminate
immediately and the error will be returned.
PRE_PROCESS, POST_PROCESS
Top
These values may be set to contain the name(s) of template files
(relative to INCLUDE_PATH) which should be processed
immediately before and/or after each template. These do not get added to
templates processed into a document via directives such as
INCLUDE, PROCESS, WRAPPER etc.
my $template = Template->new({
PRE_PROCESS => 'header',
POST_PROCESS => 'footer',
};
Multiple templates may be specified as a reference to a list. Each is processed in the order defined.
my $template = Template->new({
PRE_PROCESS => [ 'config', 'header' ],
POST_PROCESS => 'footer',
};
Alternately, multiple template may be specified as a single string,
delimited by ':'. This delimiter string can be changed via
the DELIMITER option.
my $template = Template->new({
PRE_PROCESS => 'config:header',
POST_PROCESS => 'footer',
};
The PRE_PROCESS and POST_PROCESS templates are
evaluated in the same variable context as the main document and may
define or update variables for subsequent use.
config:
[% # set some site-wide variables bgcolor = '#ffffff' version = 2.718 %]
header:
[% DEFAULT title = 'My Funky Web Site' %]
<html>
<head>
<title>[% title %]</title>
</head>
<body bgcolor="[% bgcolor %]">
footer:
<hr>
Version [% version %]
</body>
</html>
The Template::Document object representing the main template being
processed is available within PRE_PROCESS and
POST_PROCESS templates as the template
variable. Metadata items defined via the META directive may
be accessed accordingly.
$template->process('mydoc.html', $vars);
mydoc.html:
[% META title = 'My Document Title' %] blah blah blah ...
header:
<html>
<head>
<title>[% template.title %]</title>
</head>
<body bgcolor="[% bgcolor %]">
PROCESS
Top
The PROCESS option may be set to contain the name(s) of
template files (relative to INCLUDE_PATH) which should be
processed instead of the main template passed to the Template Template#process() method. This can be used to
apply consistent wrappers around all templates, similar to the use of
PRE_PROCESS and POST_PROCESS templates.
my $template = Template->new({
PROCESS => 'content',
};
# processes 'content' instead of 'foo.html'
$template->process('foo.html');
A reference to the original template is available in the
template variable. Metadata items can be inspected and the
template can be processed by specifying it as a variable reference (i.e.
prefixed by $) to an INCLUDE,
PROCESS or WRAPPER directive.
content:
<html>
<head>
<title>[% template.title %]</title>
</head>
<body>
<!-- begin content -->
[% PROCESS $template %]
<!-- end content -->
<hr>
© Copyright [% template.copyright %]
</body>
</html>
foo.html:
[% META title = 'The Foo Page' author = 'Fred Foo' copyright = '2000 Fred Foo' %] <h1>[% template.title %]</h1> Welcome to the Foo Page, blah blah blah
output:
<html>
<head>
<title>The Foo Page</title>
</head>
<body>
<!-- begin content -->
<h1>The Foo Page</h1>
Welcome to the Foo Page, blah blah blah
<!-- end content -->
<hr>
© Copyright 2000 Fred Foo
</body>
</html>
WRAPPER
Top
The WRAPPER option can be used to specify one or more
templates which should be used to wrap around the output of the main page
template. The main template is processed first (or any
PROCESS template(s)) and the output generated is then passed
as the content variable to the WRAPPER
template(s) as they are processed.
my $template = Template->new({
WRAPPER => 'wrapper',
};
# process 'foo' then wrap in 'wrapper'
$template->process('foo', { message => 'Hello World!' });
wrapper:
<wrapper> [% content %] </wrapper>
foo:
This is the foo file! Message: [% message %]
The output generated from this example is:
<wrapper> This is the foo file! Message: Hello World! </wrapper>
You can specify more than one WRAPPER template by setting
the value to be a reference to a list of templates. The
WRAPPER templates will be processed in reverse order with
the output of each being passed to the next (or previous, depending on
how you look at it) as the 'content' variable. It sounds complicated, but
the end result is that it just "Does The Right Thing" to make wrapper
templates nest in the order you specify.
my $template = Template->new({
WRAPPER => [ 'outer', 'inner' ],
};
# process 'foo' then wrap in 'inner', then in 'outer'
$template->process('foo', { message => 'Hello World!' });
outer:
<outer> [% content %] </outer>
inner:
<inner> [% content %] </inner>
The output generated is then:
<outer> <inner> This is the foo file! Message: Hello World! </inner> </outer>
One side-effect of the "inside-out" processing of the
WRAPPER configuration item (and also the
WRAPPER directive) is that any variables set in the template
being wrapped will be visible to the template doing the wrapping, but not
the other way around.
You can use this to good effect in allowing page templates to set pre-defined values which are then used in the wrapper templates. For example, our main page template 'foo' might look like this:
foo:
[% page = {
title = 'Foo Page'
subtitle = 'Everything There is to Know About Foo'
author = 'Frank Oliver Octagon'
}
%]
<p>
Welcome to the page that tells you everything about foo
blah blah blah...
</p>
The foo template is processed before the wrapper template
meaning that the page data structure will be defined for use
in the wrapper template.
wrapper:
<html>
<head>
<title>[% page.title %]</title>
</head>
<body>
<h1>[% page.title %]</h1>
<h2>[% page.subtitle %]</h1>
<h3>by [% page.author %]</h3>
[% content %]
</body>
</html>
It achieves the same effect as defining META items which are
then accessed via the template variable (which you are still
free to use within WRAPPER templates), but gives you more
flexibility in the type and complexity of data that you can define.
ERROR
Top
The ERROR (or ERRORS if you prefer)
configuration item can be used to name a single template or specify a
hash array mapping exception types to templates which should be used for
error handling. If an uncaught exception is raised from within a template
then the appropriate error template will instead be processed.
If specified as a single value then that template will be processed for all uncaught exceptions.
my $template = Template->new({
ERROR => 'error.html'
});
If the ERROR item is a hash reference the keys are assumed
to be exception types and the relevant template for a givePROCESS
templates are defined then they are instead processed in turn. In this
case, one of the PROCESS templates is responsible for
processing the main template, by a directive such as:
[% PROCESS $template %]
The output of processing the main template or the PROCESS
template(s) is then wrapped in any WRAPPER templates, if
defined. WRAPPER templates don't need to worry about
explicitly processing the template because it will have been done for
them already. Instead WRAPPER templates access the content
they are wrapping via the content variable.
wrapper before [% content %] wrapper after
This output generated from processing the main template, and/or any
PROCESS or WRAPPER templates is added to the
output buffer. Finally, any POST_PROCESS templates are
processed and their output is also added to the output buffer which is
then returned.
If the main template throws an exception during processing then any
relevant template(s) defined via the ERROR option will be
processed instead. If defined and successfully processed, the output from
the error template will be added to the output buffer in place of the
template that generated the error and processing will continue, applying
any WRAPPER and POST_PROCESS templates. If no
relevant ERROR option is defined, or if the error occurs in
one of the PRE_PROCESS, WRAPPER or
POST_PROCESS templates, then the process will terminate
immediately and the error will be returned.
PRE_PROCESS, POST_PROCESS
Top
These values may be set to contain the name(s) of template files
(relative to INCLUDE_PATH) which should be processed
immediately before and/or after each template. These do not get added to
templates processed into a document via directives such as
INCLUDE, PROCESS, WRAPPER etc.
my $template = Template->new({
PRE_PROCESS => 'header',
POST_PROCESS => 'footer',
};
Multiple templates may be specified as a reference to a list. Each is processed in the order defined.
my $template = Template->new({
PRE_PROCESS => [ 'config', 'header' ],
POST_PROCESS => 'footer',
};
Alternately, multiple template may be specified as a single string,
delimited by ':'. This delimiter string can be changed via
the DELIMITER option.
my $template = Template->new({
PRE_PROCESS => 'config:header',
POST_PROCESS => 'footer',
};
The PRE_PROCESS and POST_PROCESS templates are
evaluated in the same variable context as the main document and may
define or update variables for subsequent use.
config:
[% # set some site-wide variables bgcolor = '#ffffff' version = 2.718 %]
header:
[% DEFAULT title = 'My Funky Web Site' %]
<html>
<head>
<title>[% title %]</title>
</head>
<body bgcolor="[% bgcolor %]">
footer:
<hr>
Version [% version %]
</body>
</html>
The Template::Document object representing the main template being
processed is available within PRE_PROCESS and
POST_PROCESS templates as the template
variable. Metadata items defined via the META directive may
be accessed accordingly.
$template->process('mydoc.html', $vars);
mydoc.html:
[% META title = 'My Document Title' %] blah blah blah ...
header:
<html>
<head>
<title>[% template.title %]</title>
</head>
<body bgcolor="[% bgcolor %]">
PROCESS
Top
The PROCESS option may be set to contain the name(s) of
template files (relative to INCLUDE_PATH) which should be
processed instead of the main template passed to the Template Template#process() method. This can be used to
apply consistent wrappers around all templates, similar to the use of
PRE_PROCESS and POST_PROCESS templates.
my $template = Template->new({
PROCESS => 'content',
};
# processes 'content' instead of 'foo.html'
$template->process('foo.html');
A reference to the original template is available in the
template variable. Metadata items can be inspected and the
template can be processed by specifying it as a variable reference (i.e.
prefixed by $) to an INCLUDE,
PROCESS or WRAPPER directive.
content:
<html>
<head>
<title>[% template.title %]</title>
</head>
<body>
<!-- begin content -->
[% PROCESS $template %]
<!-- end content -->
<hr>
© Copyright [% template.copyright %]
</body>
</html>
foo.html:
[% META title = 'The Foo Page' author = 'Fred Foo' copyright = '2000 Fred Foo' %] <h1>[% template.title %]</h1> Welcome to the Foo Page, blah blah blah
output:
<html>
<head>
<title>The Foo Page</title>
</head>
<body>
<!-- begin content -->
<h1>The Foo Page</h1>
Welcome to the Foo Page, blah blah blah
<!-- end content -->
<hr>
© Copyright 2000 Fred Foo
</body>
</html>
WRAPPER
Top
The WRAPPER option can be used to specify one or more
templates which should be used to wrap around the output of the main page
template. The main template is processed first (or any
PROCESS template(s)) and the output generated is then passed
as the content variable to the WRAPPER
template(s) as they are processed.
my $template = Template->new({
WRAPPER => 'wrapper',
};
# process 'foo' then wrap in 'wrapper'
$template->process('foo', { message => 'Hello World!' });
wrapper:
<wrapper> [% content %] </wrapper>
foo:
This is the foo file! Message: [% message %]
The output generated from this example is:
<wrapper> This is the foo file! Message: Hello World! </wrapper>
You can specify more than one WRAPPER template by setting
the value to be a reference to a list of templates. The
WRAPPER templates will be processed in reverse order with
the output of each being passed to the next (or previous, depending on
how you look at it) as the 'content' variable. It sounds complicated, but
the end result is that it just "Does The Right Thing" to make wrapper
templates nest in the order you specify.
my $template = Template->new({
WRAPPER => [ 'outer', 'inner' ],
};
# process 'foo' then wrap in 'inner', then in 'outer'
$template->process('foo', { message => 'Hello World!' });
outer:
<outer> [% content %] </outer>
inner:
<inner> [% content %] </inner>
The output generated is then:
<outer> <inner> This is the foo file! Message: Hello World! </inner> </outer>
One side-effect of the "inside-out" processing of the
WRAPPER configuration item (and also the
WRAPPER directive) is that any variables set in the template
being wrapped will be visible to the template doing the wrapping, but not
the other way around.
You can use this to good effect in allowing page templates to set pre-defined values which are then used in the wrapper templates. For example, our main page template 'foo' might look like this:
foo:
[% page = {
title = 'Foo Page'
subtitle = 'Everything There is to Know About Foo'
author = 'Frank Oliver Octagon'
}
%]
<p>
Welcome to the page that tells you everything about foo
blah blah blah...
</p>
The foo template is processed before the wrapper template
meaning that the page data structure will be defined for use
in the wrapper template.
wrapper:
<html>
<head>
<title>[% page.title %]</title>
</head>
<body>
<h1>[% page.title %]</h1>
<h2>[% page.subtitle %]</h1>
<h3>by [% page.author %]</h3>
[% content %]
</body>
</html>
It achieves the same effect as defining META items which are
then accessed via the template variable (which you are still
free to use within WRAPPER templates), but gives you more
flexibility in the type and complexity of data that you can define.
ERROR
Top
The ERROR (or ERRORS if you prefer)
configuration item can be used to name a single template or specify a
hash array mapping exception types to templates which should be used for
error handling. If an uncaught exception is raised from within a template
then the appropriate error template will instead be processed.
If specified as a single value then that template will be processed for all uncaught exceptions.
my $template = Template->new({
ERROR => 'error.html'
});
If the ERROR item is a hash reference the keys are assumed
to be exception types and the relevant template for a givePROCESS
templates are defined then they are instead processed in turn. In this
case, one of the PROCESS templates is responsible for
processing the main template, by a directive such as:
[% PROCESS $template %]
The output of processing the main template or the PROCESS
template(s) is then wrapped in any WRAPPER templates, if
defined. WRAPPER templates don't need to worry about
explicitly processing the template because it will have been done for
them already. Instead WRAPPER templates access the content
they are wrapping via the content variable.
wrapper before [% content %] wrapper after
This output generated from processing the main template, and/or any
PROCESS or WRAPPER templates is added to the
output buffer. Finally, any POST_PROCESS templates are
processed and their output is also added to the output buffer which is
then returned.
If the main template throws an exception during processing then any
relevant template(s) defined via the ERROR option will be
processed instead. If defined and successfully processed, the output from
the error template will be added to the output buffer in place of the
template that generated the error and processing will continue, applying
any WRAPPER and POST_PROCESS templates. If no
relevant ERROR option is defined, or if the error occurs in
one of the PRE_PROCESS, WRAPPER or
POST_PROCESS templates, then the process will terminate
immediately and the error will be returned.
PRE_PROCESS, POST_PROCESS
Top
These values may be set to contain the name(s) of template files
(relative to INCLUDE_PATH) which should be processed
immediately before and/or after each template. These do not get added to
templates processed into a document via directives such as
INCLUDE, PROCESS, WRAPPER etc.
my $template = Template->new({
PRE_PROCESS => 'header',
POST_PROCESS => 'footer',
};
Multiple templates may be specified as a reference to a list. Each is processed in the order defined.
my $template = Template->new({
PRE_PROCESS => [ 'config', 'header' ],
POST_PROCESS => 'footer',
};
Alternately, multiple template may be specified as a single string,
delimited by ':'. This delimiter string can be changed via
the DELIMITER option.
my $template = Template->new({
PRE_PROCESS => 'config:header',
POST_PROCESS => 'footer',
};
The PRE_PROCESS and POST_PROCESS templates are
evaluated in the same variable context as the main document and may
define or update variables for subsequent use.
config:
[% # set some site-wide variables bgcolor = '#ffffff' version = 2.718 %]
header:
[% DEFAULT title = 'My Funky Web Site' %]
<html>
<head>
<title>[% title %]</title>
</head>
<body bgcolor="[% bgcolor %]">
footer:
<hr>
Version [% version %]
</body>
</html>
The Template::Document object representing the main template being
processed is available within PRE_PROCESS and
POST_PROCESS templates as the template
variable. Metadata items defined via the META directive may
be accessed accordingly.
$template->process('mydoc.html', $vars);
mydoc.html:
[% META title = 'My Document Title' %] blah blah blah ...
header:
<html>
<head>
<title>[% template.title %]</title>
</head>
<body bgcolor="[% bgcolor %]">
PROCESS
Top
The PROCESS option may be set to contain the name(s) of
template files (relative to INCLUDE_PATH) which should be
processed instead of the main template passed to the Template Template#process() method. This can be used to
apply consistent wrappers around all templates, similar to the use of
PRE_PROCESS and POST_PROCESS templates.
my $template = Template->new({
PROCESS => 'content',
};
# processes 'content' instead of 'foo.html'
$template->process('foo.html');
A reference to the original template is available in the
template variable. Metadata items can be inspected and the
template can be processed by specifying it as a variable reference (i.e.
prefixed by $) to an INCLUDE,
PROCESS or WRAPPER directive.
content:
<html>
<head>
<title>[% template.title %]</title>
</head>
<body>
<!-- begin content -->
[% PROCESS $template %]
<!-- end content -->
<hr>
© Copyright [% template.copyright %]
</body>
</html>
foo.html:
[% META title = 'The Foo Page' author = 'Fred Foo' copyright = '2000 Fred Foo' %] <h1>[% template.title %]</h1> Welcome to the Foo Page, blah blah blah
output:
<html>
<head>
<title>The Foo Page</title>
</head>
<body>
<!-- begin content -->
<h1>The Foo Page</h1>
Welcome to the Foo Page, blah blah blah
<!-- end content -->
<hr>
© Copyright 2000 Fred Foo
</body>
</html>
WRAPPER
Top
The WRAPPER option can be used to specify one or more
templates which should be used to wrap around the output of the main page
template. The main template is processed first (or any
PROCESS template(s)) and the output generated is then passed
as the content variable to the WRAPPER
template(s) as they are processed.
my $template = Template->new({
WRAPPER => 'wrapper',
};
# process 'foo' then wrap in 'wrapper'
$template->process('foo', { message => 'Hello World!' });
wrapper:
<wrapper> [% content %] </wrapper>
foo:
This is the foo file! Message: [% message %]
The output generated from this example is:
<wrapper> This is the foo file! Message: Hello World! </wrapper>
You can specify more than one WRAPPER template by setting
the value to be a reference to a list of templates. The
WRAPPER templates will be processed in reverse order with
the output of each being passed to the next (or previous, depending on
how you look at it) as the 'content' variable. It sounds complicated, but
the end result is that it just "Does The Right Thing" to make wrapper
templates nest in the order you specify.
my $template = Template->new({
WRAPPER => [ 'outer', 'inner' ],
};
# process 'foo' then wrap in 'inner', then in 'outer'
$template->process('foo', { message => 'Hello World!' });
outer:
<outer> [% content %] </outer>
inner:
<inner> [% content %] </inner>
The output generated is then:
<outer> <inner> This is the foo file! Message: Hello World! </inner> </outer>
One side-effect of the "inside-out" processing of the
WRAPPER configuration item (and also the
WRAPPER directive) is that any variables set in the template
being wrapped will be visible to the template doing the wrapping, but not
the other way around.
You can use this to good effect in allowing page templates to set pre-defined values which are then used in the wrapper templates. For example, our main page template 'foo' might look like this:
foo:
[% page = {
title = 'Foo Page'
subtitle = 'Everything There is to Know About Foo'
author = 'Frank Oliver Octagon'
}
%]
<p>
Welcome to the page that tells you everything about foo
blah blah blah...
</p>
The foo template is processed before the wrapper template
meaning that the page data structure will be defined for use
in the wrapper template.
wrapper:
<html>
<head>
<title>[% page.title %]</title>
</head>
<body>
<h1>[% page.title %]</h1>
<h2>[% page.subtitle %]</h1>
<h3>by [% page.author %]</h3>
[% content %]
</body>
</html>
It achieves the same effect as defining META items which are
then accessed via the template variable (which you are still
free to use within WRAPPER templates), but gives you more
flexibility in the type and complexity of data that you can define.
ERROR
Top
The ERROR (or ERRORS if you prefer)
configuration item can be used to name a single template or specify a
hash array mapping exception types to templates which should be used for
error handling. If an uncaught exception is raised from within a template
then the appropriate error template will instead be processed.
If specified as a single value then that template will be processed for all uncaught exceptions.
my $template = Template->new({
ERROR => 'error.html'
});
If the ERROR item is a hash reference the keys are assumed
to be exception types and the relevant template for a givePROCESS
templates are defined then they are instead processed in turn. In this
case, one of the PROCESS templates is responsible for
processing the main template, by a directive such as:
[% PROCESS $template %]
The output of processing the main template or the PROCESS
template(s) is then wrapped in any WRAPPER templates, if
defined. WRAPPER templates don't need to worry about
explicitly processing the template because it will have been done for
them already. Instead WRAPPER templates access the content
they are wrapping via the content variable.
wrapper before [% content %] wrapper after
This output generated from processing the main template, and/or any
PROCESS or WRAPPER templates is added to the
output buffer. Finally, any POST_PROCESS templates are
processed and their output is also added to the output buffer which is
then returned.
If the main template throws an exception during processing then any
relevant template(s) defined via the ERROR option will be
processed instead. If defined and successfully processed, the output from
the error template will be added to the output buffer in place of the
template that generated the error and processing will continue, applying
any WRAPPER and POST_PROCESS templates. If no
relevant ERROR option is defined, or if the error occurs in
one of the PRE_PROCESS, WRAPPER or
POST_PROCESS templates, then the process will terminate
immediately and the error will be returned.
PRE_PROCESS, POST_PROCESS
Top
These values may be set to contain the name(s) of template files
(relative to INCLUDE_PATH) which should be processed
immediately before and/or after each template. These do not get added to
templates processed into a document via directives such as
INCLUDE, PROCESS, WRAPPER etc.
my $template = Template->new({
PRE_PROCESS => 'header',
POST_PROCESS => 'footer',
};
Multiple templates may be specified as a reference to a list. Each is processed in the order defined.
my $template = Template->new({
PRE_PROCESS => [ 'config', 'header' ],
POST_PROCESS => 'footer',
};
Alternately, multiple template may be specified as a single string,
delimited by ':'. This delimiter string can be changed via
the DELIMITER option.
my $template = Template->new({
PRE_PROCESS => 'config:header',
POST_PROCESS => 'footer',
};
The PRE_PROCESS and POST_PROCESS templates are