Views can also be used to save the values of any existing variables, or to create new ones at the point
at which the view is defined. Unlike simple template metadata ("META") which can only contain static
string values, the view initialisation block can contain any template directives and generate any kind of
dynamic output and/or data items.
[% VIEW my_web_site %]
[% view.title = title or 'My Cool Web Site' %]
[% view.author = "$abw.name, $abw.email" %]
[% view.sidebar = INCLUDE my/sidebar.tt2 %]
[% END %]
Note that additional data items can be specified as arguments to the "VIEW" directive. Anything that
doesn't look like a configuration parameter is assumed to be a data item. This can be a little
hazardous, of course, because you never know when a new configuration item might get added which
interferes with your data.
[% VIEW my_web_site
# config options
prefix = 'my/'
# misc data
title = title or 'My Cool Web Site'
author = "$abw.name, $abw.email"
sidebar = INCLUDE my/sidebar.tt2
%]
...
[% END %]
Outside of the view definition you can access the view variables as, for example:
[% my_web_site.title %]
One important feature is the equivalence of simple variables and templates. You can implement the view
item '"title"' as a simple variable, a template defined in an external file, possibly with a
prefix/suffix automatically appended, or as a local "BLOCK" definition within the "[% VIEW %] ... [% END
%]" definition. If you use the syntax above then the view will Do The Right Thing to return the
appropriate output.
At the "END" of the "VIEW" definition the view is "sealed" to prevent you from accidentally updating any
variable values. If you attempt to change the value of a variable after the "END" of the "VIEW"
definition block then a "view" error will be thrown.
[% TRY;
my_web_site.title = 'New Title';
CATCH;
error;
END
%]
The error above will be reported as:
view error - cannot update item in sealed view: title
The same is true if you pass a parameter to a view variable. This is interpreted as an attempt to update
the variable and will raise the same warning.
[% my_web_site.title('New Title') %] # view error!
You can set the "silent" parameter to have the view ignore these parameters and simply return the
variable value.
[% VIEW my_web_site
silent = 1
title = title or 'My Cool Web Site'
# ... ;
END
%]
[% my_web_site.title('Blah Blah') %] # My Cool Web Site
Alternately, you can specify that a view is unsealed allowing existing variables to be updated and new
variables defined.
[% VIEW my_web_site
sealed = 0
title = title or 'My Cool Web Site'
# ... ;
END
%]
[% my_web_site.title('Blah Blah') %] # Blah Blah
[% my_web_site.title %] # Blah Blah
Inheritance,DelegationandReuse
Views can be inherited from previously defined views by use of the "base" parameter. This example shows
how a base class view is defined which applies a "view/default/" prefix to all template names.
[% VIEW my.view.default
prefix = 'view/default/';
END
%]
Thus the directive:
[% my.view.default.header(title='Hello World') %]
is now equivalent to:
[% INCLUDE view/default/header title='Hello World' %]
A second view can be defined which specifies the default view as a base.
[% VIEW my.view.fancy
base = my.view.default
prefix = 'view/fancy/';
END
%]
Now the directive:
[% my.view.fancy.header(title='Hello World') %]
will resolve to:
[% INCLUDE view/fancy/header title='Hello World' %]
or if that doesn't exist, it will be handled by the base view as:
[% INCLUDE view/default/header title='Hello World' %]
When a parent view is specified via the "base" parameter, the delegation of a view to its parent for
fetching templates and accessing user defined variables is automatic. You can also implement your own
inheritance, delegation or other reuse patterns by explicitly delegating to other views.
[% BLOCK foo %]
public foo block
[% END %]
[% VIEW plain %]
[% BLOCK foo %]
<plain>[% PROCESS foo %]</plain>
[% END %]
[% END %]
[% VIEW fancy %]
[% BLOCK foo %]
[% plain.foo | replace('plain', 'fancy') %]
[% END %]
[% END %]
[% plain.foo %] # <plain>public foo block</plain>
[% fancy.foo %] # <fancy>public foo block</fancy>
Note that the regular "INCLUDE/PROCESS/WRAPPER" directives work entirely independently of views and will
always get the original, unaltered template name rather than any local per-view definition.
Self-Reference
A reference to the view object under definition is available with the "VIEW ... END" block by its
specified name and also by the special name '"view"' (similar to the "my $self = shift;" in a Perl method
or the '"this"' pointer in C++, etc). The view is initially unsealed allowing any data items to be
defined and updated within the "VIEW ... END" block. The view is automatically sealed at the end of the
definition block, preventing any view data from being subsequently changed.
(NOTE: sealing should be optional. As well as sealing a view to prevent updates ("SEALED"), it should be
possible to set an option in the view to allow external contexts to update existing variables ("UPDATE")
or even create totally new view variables ("CREATE")).
[% VIEW fancy %]
[% fancy.title = 'My Fancy Title' %]
[% fancy.author = 'Frank Open' %]
[% fancy.col = { bg => '#ffffff', bar => '#a0a0ff' } %]
[% END %]
or
[% VIEW fancy %]
[% view.title = 'My Fancy Title' %]
[% view.author = 'Frank Open' %]
[% view.col = { bg => '#ffffff', bar => '#a0a0ff' } %]
[% END %]
It makes no real difference in this case if you refer to the view by its name, '"fancy"', or by the
general name, '"view"'. Outside of the view block, however, you should always use the given name,
'"fancy"':
[% fancy.title %]
[% fancy.author %]
[% fancy.col.bg %]
The choice of given name or '"view"' is much more important when it comes to "BLOCK" definitions within a
"VIEW". It is generally recommended that you use '"view"' inside a "VIEW" definition because this is
guaranteed to be correctly defined at any point in the future when the block gets called. The original
name of the view might have long since been changed or reused but the self-reference via '"view"' should
always be intact and valid.
Take the following VIEW as an example:
[% VIEW foo %]
[% view.title = 'Hello World' %]
[% BLOCK header %]
Title: [% view.title %]
[% END %]
[% END %]
Even if we rename the view, or create a new "foo" variable, the header block still correctly accesses the
"title" attribute of the view to which it belongs. Whenever a view "BLOCK" is processed, the "view"
variable is always updated to contain the correct reference to the view object to which it belongs.
[% bar = foo %]
[% foo = { title => "New Foo" } %] # no problem
[% bar.header %] # => Title: Hello World
SavingReferencestoExternalViews
When it comes to view inheritance, it's always a good idea to take a local copy of a parent or delegate
view and store it as an attribute within the view for later use. This ensures that the correct view
reference is always available, even if the external name of a view has been changed.
[% VIEW plain %]
...
[% END %]
[% VIEW fancy %]
[% view.plain = plain %]
[% BLOCK foo %]
[% view.plain.foo | replace('plain', 'fancy') %]
[% END %]
[% END %]
[% plain.foo %] # => <plain>public foo block</plain>
[% plain = 'blah' %] # no problem
[% fancy.foo %] # => <fancy>public foo block</fancy>
ViewsasDataPresenters
Another key role of a view is to act as a dispatcher to automatically apply the correct template to
present a particular object or data item. This is handled via the print() method.
Here's an example:
[% VIEW foo %]
[% BLOCK text %]
Some text: [% item %]
[% END %]
[% BLOCK hash %]
a hash:
[% FOREACH key = item.keys.sort -%]
[% key %] => [% item.$key %]
[% END -%]
[% END %]
[% BLOCK list %]
a list: [% item.sort.join(', ') %]
[% END %]
[% END %]
We can now use the view to print text, hashes or lists. The print() method includes the right template
depending on the typing of the argument (or arguments) passed.
[% some_text = 'I read the news today, oh boy.' %]
[% a_hash = { house => 'Lords', hall => 'Albert' } %]
[% a_list = [ 'sure', 'Nobody', 'really' ] %]
[% view.print(some_text) %]
# Some text: I read the news today, oh boy.
[% view.print(a_hash) %]
# a hash:
hall => Albert
house => Lords
[% view.print(a_list) %]
# a list: Nobody, really, sure
You can also provide templates to print objects of any other class. The class name is mapped to a
template name with all non-word character sequences such as '"::"' converted to a single '"_"'.
[% VIEW foo %]
[% BLOCK Foo_Bar %]
a Foo::Bar object:
thingies: [% view.print(item.thingies) %]
doodahs: [% view.print(item.doodahs) %]
[% END %]
[% END %]
[% USE fubar = Foo::Bar(...) %]
[% foo.print(fubar) %]
Note how we use the view object to display various items within the objects ('"thingies"' and
'"doodahs"'). We don't need to worry what kind of data these represent (text, list, hash, etc) because
we can let the view worry about it, automatically mapping the data type to the correct template.
Views may define their own type => template map.
[% VIEW foo
map = { TEXT => 'plain_text',
ARRAY => 'show_list',
HASH => 'show_hash',
My::Module => 'template_name'
default => 'any_old_data'
}
%]
[% BLOCK plain_text %]
...
[% END %]
...
[% END %]
They can also provide a "default" map entry, specified as part of the "map" hash or as a parameter by
itself.
[% VIEW foo
map = { ... },
default = 'whatever'
%]
...
[% END %]
or
[% VIEW foo %]
[% view.map = { ... }
view.default = 'whatever'
%]
...
[% END %]
The print() method provides one more piece of magic. If you pass it a reference to an object which
provides a present() method, then the method will be called passing the view as an argument. This then
gives any object a chance to determine how it should be presented via the view.
package Foo::Bar;
...
sub present {
my ($self, $view) = @_;
return "a Foo::Bar object:\n"
. "thingies: " . $view->print($self->{ _THINGIES }) . "\n"
. "doodahs: " . $view->print($self->{ _DOODAHS }) . "\n";
}
The object is free to delve deeply into its innards and mess around with its own private data, before
presenting the relevant data via the view. In a more complex example, a present() method might walk part
of a tree making calls back against the view to present different nodes within the tree. We may not want
to expose the internal structure of the tree (because that would break encapsulation and make our
presentation code dependant on it) but we want to have some way of walking the tree and presenting items
found in a particular manner.
This is known as StructureShyTraversal. Our view object doesn't require prior knowledge about the
internal structure of any data set to be able to traverse it and present the data contained therein. The
data items themselves, via the present() method, can implement the internal iterators to guide the view
along the right path to presentation happiness.
The upshot is that you can use views to greatly simplify the display of data structures like "XML::DOM"
trees. The documentation for the "Template::Plugin::XML::DOM" module contains an example of this. In
essence, it looks something like this:
XML source:
<user name="Andy Wardley">
<project id="iCan" title="iCan, but theyCan't"/>
<project id="p45" title="iDid, but theyDidn't"/>
</user>
TT View:
[% VIEW fancy %]
[% BLOCK user %]
User: [% item.name %]
[% item.content(myview) %]
[% END %]
[% BLOCK project %]
Project: [% project.id %] - [% project.name %]
[% END %]
[% END %]
Generate view:
[% USE dom = XML.DOM %]
[% fancy.print(dom.parse(xml_source)) %]
Output:
User: Andy Wardley
Project: iCan - iCan, but theyCan't
Project: p45 - iDid, but theyDidn't
The same approach can be applied to many other areas. Here's an example from the "File"/"Directory"
plugins.
[% VIEW myview %]
[% BLOCK file %]
- [% item.name %]
[% END %]
[% BLOCK directory %]
* [% item.name %]
[% item.content(myview) FILTER indent %]
[% END %]
[% END %]
[% USE dir = Directory(dirpath) %]
[% myview.print(dir) %]
And here's the same approach use to convert POD documentation to any other format via template.
[% # load Pod plugin and parse source file into Pod Object Model
USE Pod;
pom = Pod.parse_file(my_pod_file);
# define view to map all Pod elements to "pod/html/xxx" templates
VIEW pod2html
prefix='pod/html';
END;
# now print document via view (i.e. as HTML)
pod2html.print(pom)
%]
Here we simply define a template prefix for the view which causes the view to look for "pod/html/head1",
"pod/html/head2", "pod/html/over" as templates to present the different sections of the parsed Pod
document.
There are some examples in the Template Toolkit test suite: t/pod.t and t/view.t which may shed some more
light on this. See the distribution sub-directory examples/pod/html for examples of Pod -> HTML
templates.
perl v5.40.0 2024-10-20 Template::Manual::Views(3pm)
Install Now
PNG Icons
