Free template software for linux

Template::Ast is a Perl module to process ASTs for Perl Template Toolkit.

SYNOPSIS

use Template::Ast;

# Rebuild AST stored in file:
$ast = Template::Ast->read(foo.ast) or
die Template::Ast->error();

# Writing existing AST to file:
$ast = { Marry => [24, F], John => [21, M] };
Template::Ast->write($ast, foo.ast) or
die Template::Ast->error();

$ast = Template::Ast->merge([1,2,3], undef); # [1,2,3]
$ast = Template::Ast->merge(undef, [1,2,3]); # [1,2,3]
$ast = Template::Ast->merge(undef, undef); # undef

$ast = Template::Ast->merge({A=>1,B=>2}, [C]); # [C]
$ast = Template::Ast->merge([1,2,3], [5,6]); # [5,6]
$ast = Template::Ast->merge([{A=>1},2], 5); # 5

$ast = Template::Ast->merge({A=>1,B=>2}, {C=>3}); # {A=>1,B=>2,C=>3}
$ast = Template::Ast->merge({A=>1,B=>2}, {B=>3}); # {A=>1,B=>3}

# {A=>1,B=>2}
$ast = Template::Ast->merge({A=>1,B=>undef}, {A=>undef,B=>2});

Template::Ast->merge(
{A=>1,B=>{C=>1,D=>2}},
{B=>{C=>1,D=>3,E=>4}}
); # {A=>1,B=>{C=>1,D=>3,E=>4}}

Template::Ast->merge(
{A=>1,B=>{C=>[1,2]}},
{B=>{C=>[3,4]}}
); # {A=>1,B=>{C=>[3,4]}}

print Template::Ast->dump([$vars], [vars]);

ASTs are essential in the programming model based on Perl Template Toolkit. This module provides some easy interface to do the dirty work involved in AST handling. The term AST used here are referred to any Perl referece pointed to a complex data structure, such as a nested hash, a nested array, or such.

Template::FAQ contains Frequently Asked Questions about the Template Toolkit.

Template Toolkit Language

Why doesnt [% a = b IF c %] work as expected?

Because the parser interprets it as

[% a = (b IF c) %]

Do this instead:

[% SET a = b IF c %]

If Im using TT to write out a TT template, is there a good way to escape [% and %]?

You can do this:

[% stag = "[%"
etag = "%]"
%]

and then:

[% stag; hello; etag %]

Or something like:

[% TAGS [- -] %]
[- INCLUDE foo -] # is a directive
[% INCLUDE foo %] # not a directive, just plain text, passed through

How do I iterate over a hash?

This is covered in the Template::Manual::VMethods section of the manual page. A list of all the keys that are in the hash can be obtained with the keys virtual method. You can then iterate over that list and by looking up each key in turn get the value.

[% FOREACH key = product.keys %]
[% key %] => [% product.$key %]
[% END %]

Pod::Template is a Perl module for building pod documentation from templates.

SYNOPSIS

### As a module ###
use Pod::Template;
my $parser = new Pod::Template;
$parser->parse( template => documentation.ptmpl );

print $parser->as_string


### As a script ###
$ podtmpl -I dir1 -I dir2 documentation.ptmpl


### A simple module prepared to use Pod::Template ###
package My::Module;

=Template print_me
=head2 print_me( $string )

Prints out its argument.

=cut

sub print_me { print shift; return 1 }


### A simple pod file named Extra/Additional.pod ###
=pod
=Template return_vals

This subroutine returns 1 for success and undef for failure.

=cut


### A simple Pod::Template template ###
=Include My::Module
=Include Extra/Additional.pod as Extra

=pod

=head1 SYNOPSIS

use My::Module

My::Module::print_me(some text);

=head2 Functions

=Insert My::Module->print_me

=Insert Extra->return_vals

=cut

Writing documentation on a project maintained by several people which spans more than one module is a tricky matter. There are many things to consider:

Location
Should pod be inline (above every function), at the bottom of the module, or in a distinct file? The first is easier for the developers, but the latter two are better for the pod maintainers.

Order
What order should the documentation be in? Does it belong in the order in which the functions are written, or ordered by another principle, such as frequency of use or function type? Again, the first option is better for the developers, while the second two are better for the user.

References
How should a function in another file be mentioned? Should the documentation simply say see Other::Module, or should it include the relevant section? Duplication means that the documentation is more likely to be outdated, but its bad for a user to have to read numerous documents to simply find out what an inherited method does.

Headers & Footers
What should be done with standard headers and footers? Should they be pasted in to every file, or can the main file be assumed to cover the entire project?

Pod::Template offers a solution to these problems: documentation is built up from templates.

Template::Magic is a Perl module for magic merger of runtime values with templates.

SYNOPSIS

Just add these 2 magic lines to your code...

use Template::Magic;
Template::Magic->new->print( /path/to/template );

to have all your variable and subroutines merged with the template file, or set one or more constructor array to customize the output generation as you need:

use Template::Magic qw( -compile );

$tm = new Template::Magic
paths => [ qw(/any/path /any/other/path) ] ,
markers => [ qw( < / > ) ] ,
lookups => [ %my_hash, $my_obj, main ] ,
zone_handlers => [ &my_zone_handler, _EVAL_ ] ,
value_handlers => [ DEFAULT, &my_value_handler ] ,
text_handlers => sub {print lc $_[1]} ,
output_handlers => sub {print uc $_[1]} ,
post_handlers => &my_post_handler ,
options => no_cache ;

$tm->nprint( template => /path/to/template
lookups => %my_special_hash );

Template::Plugins is a Perl module with plugin provider.

SYNOPSIS

use Template::Plugins;

$plugin_provider = Template::Plugins->new(%options);

($plugin, $error) = $plugin_provider->fetch($name, @args);

The Template::Plugins module defines a provider class which can be used to load and instantiate Template Toolkit plugin modules.

Template::Simple is a simple and fast template module.

SYNOPSIS

use Template::Simple;

my $tmpl = Template::Simple->new();

my $template = Jan 1, 2008,
author => Me, myself and I,
},
row => [
{
first => row 1 value 1,
second => row 1 value 2,
},
{
first => row 2 value 1,
second => row 2 value 2,
},
],
footer_data => {
modified => Aug 31, 2006,
},
} ;

my $rendered = $tmpl->render( $template, $data ) ;

Template::Simple has these goals:

Support most common template operations

It can recursively include other templates, replace tokens (scalars), recursively render nested chunks of text and render lists. By using simple idioms you can get conditional renderings.
Complete isolation of template from program code

This is very important as template design can be done by different people than the program logic. It is rare that one person is well skilled in both template design and also programming.
Very simple template markup (only 4 markups)

The only markups are INCLUDE, START, END and token. See MARKUP for more.

Easy to follow rendering rules

Rendering of templates and chunks is driven from a data tree. The type of the data element used in an rendering controls how the rendering happens. The data element can be a scalar or scalar reference or an array, hash or code reference.

Efficient template rendering

Rendering is very simple and uses Perls regular expressions efficiently. Because the markup is so simple less processing is needed than many other templaters. Precompiling templates is not supported yet but that optimization is on the TODO list.

Easy user extensions

User code can be called during an rendering so you can do custom renderings and plugins. Closures can be used so the code can have its own private data for use in rendering its template chunk.

Template::TT2Site is a Perl module to create standard web sites with the Template Toolkit.

SYNOPSIS

$ mkdir NewSite
$ cd NewSite
$ tt2site setup
... make your pages ...
$ tt2site build
... point your browser at html/index.html ...

tt2site is just a wrapper program. tt2site setup is equivalent to perl -MTemplate::TT2Site -e setup, and so on.

Template::TT2Site is a framework to create web sites using the Template Toolkit.

The technical structure of the site is patterned after the method described in chapter 11 of The Badger Book. The structure has been slightly simplified for ease of use, and a couple of neat features are added:

The resultant site is position independent, i.e., it only uses relative URLs to the extent possible. This makes it easy to build partial sites, and to relocate the contents.

The necessary means are provided to create multi-language sites, where each page gets a link to its translations.
The site.map hash, required for site navigation, is created automatically using minimal, position independent, directions.

This module, Template::TT2Site, provides the necessary methods to setup and maintain a site. It is used by the wrapper program, tt2site.