This is placed inside a file called header, and so the factory templates begin with:

[% INCLUDE header %] 

So if you want to supply your own look and feel to the default CRUD site, you could do so by creating custom/header, which will override the default factory header. As you can see, included files receive the template variables as well, such as config in our example.

[edit] Macros

Additionally, you can define macros to simplify repeated pieces of coding. For instance, we've seen that Maypole URLs are dissected into table, action, and arguments; the factory macros include some code to construct a link by putting these back together again:

[% 
MACRO link(table, command, additional, label) BLOCK; 
'<A HREF="' _ base _ "/" _ table _ "/" _ command _ "/" _ additional _ '">'; 
label; 
"</A>"; 
END; 
%] 

Notice here the use of Perl 6 style concatenation operators. XXX

[edit] Plugins

Of slightly less common use, but astonishing versatility, is the Template Toolkit plugin system. This provides the ability for templates to call out to Perl code. For instance, the amazingly helpful (but somewhat dangerous) Template::Plugin::Class allows you to call class methods from within TT:

 [% USE tagcloud_c = Class("HTML::TagCloud"); 
    SET tagcloud = tagcloud_c.new; 
    FOREACH tag = tags;
      tagcloud.add(...); 
    END
    tagcloud.html;
  %] 

XXX

[edit] Filters

Template Toolkit filters are a little like Unix filters - they're little routines which take an input, transform it, and spit it back out again. And just like Unix filters, they're connected to our template output with a pipe symbol. (|)

For instance, the oddly named format filter performs printf-like formatting on its input:

[% job.description | format("%60s") %] : [% job.cost %] 

We can also filter whole blocks of template content. For example, if we wanted to format the output as HTML, we could apply the html_entity filter to replace entities with their HTML encoding:

 [% FILTER html_entity %] 
   Payment terms: < 30 days. 
 [% END %] 

This turns into:

 Payment terms: < 30 days. 

Other interesting filters include the upper, lower, ucfirst and lcfirst filters to change the casing of the text; uri to URI-escape any special characters; eval to treat the text to another level of Template processing, and perl_eval to treat the output as Perl, eval that, and then add the output to the template. For a fuller list of filters with examples, see the Template::Manual::Filters documentation.

[edit] TT Within Maypole

As with any view class, TT receives certain template variables from Maypole:

Table 4.1. Template variables request The Maypole request object objects The objects to be displayed base The base URL config The Maypole::Config object classmetadata The class metadata as described in Table 1.1, “The classmetadata hash” Anything else The contents of $r->template_args is added to the set of template variables at this point.

Additionally, Maypole makes an alias for the objects it passes in; for instance, in /supporters/list/ the objects can be referred to as supporters as well as objects. If there's only one item in the objects array, it's given a singular name such as supporter. This makes the templates much easier to read.

The factory templates are written to use these template variables, and particularly the classmetadata, to provide a generic CRUD interface. When you are writing your own templates, you can use as many or as few elements of the factory templates as you like, but you will find that writing your