package Template::Flute;
use strict;
use warnings;
use Scalar::Util qw/blessed/;
use Template::Flute::Utils;
use Template::Flute::Specification::XML;
use Template::Flute::HTML;
use Template::Flute::Iterator;
use Template::Flute::Increment;
use Template::Flute::Pager;
use Template::Flute::Paginator;
=head1 NAME
Template::Flute - Modern designer-friendly HTML templating Engine
=head1 VERSION
Version 0.0132
=cut
our $VERSION = '0.0132';
=head1 SYNOPSIS
use Template::Flute;
my ($cart, $flute, %values);
$cart = [{...},{...}];
$values{cost} = ...
$flute = new Template::Flute(specification_file => 'cart.xml',
template_file => 'cart.html',
iterators => {cart => $cart},
values => \%values,
autodetect => {
disable => [qw/Foo::Bar/],
}
);
print $flute->process();
=head1 DESCRIPTION
Template::Flute enables you to completely separate web design and programming
tasks for dynamic web applications.
Templates are designed to be designer-friendly; there's no inline code or mini
templating language for your designers to learn - instead, standard HTML and CSS
classes are used, leading to HTML that can easily be understood and edited by
WYSIWYG editors and hand-coding designers alike.
An example is easier than a wordy description:
Given the following template snippet:
Mr A Test
someone@example.com
and the following specification:
Processing the above as follows:
$flute = Template::Flute->new(
template_file => 'template.html',
specification_file => 'spec.xml',
);
$flute->set_values({
customer_name => 'Bob McTest',
email => 'bob@example.com',
});;
print $flute->process;
The resulting output would be:
Bob McTest
bob@example.com
In other words, rather than including a templating language within your
templates which your designers must master and which could interfere with
previews in WYSWYG tools, CSS selectors in the template are tied to your
data structures or objects by a specification provided by the programmer.
=head2 Workflow
The easiest way to use Template::Flute is to pass all necessary parameters to
the constructor and call the process method to generate the HTML.
You can also break it down in separate steps:
=over 4
=item 1. Parse specification
Parse specification based on your specification format (e.g with
L or L.).
$xml_spec = new Template::Flute::Specification::XML;
$spec = $xml_spec->parse(q{});
=item 2. Parse template
Parse template with L object.
$template = new Template::Flute::HTML;
$template->parse(q{
Cart Example
Name
Quantity
Price
Sample Book
$1
Total
$10
},
$spec);
=item 3. Produce HTML output
$flute = new Template::Flute(template => $template,
iterators => {cart => $cart},
values => {cost => '84.94'});
$flute->process();
=back
=head1 CONSTRUCTOR
=head2 new
Create a Template::Flute object with the following parameters:
=over 4
=item specification_file
Specification file name.
=item specification_parser
Select specification parser. This can be either the full class name
like L or the last part for classes residing
in the Template::Flute::Specification namespace.
=item specification
Specification object or specification as string.
=item template_file
HTML template file.
=item template
L object or template as string.
=item database
L object.
=item filters
Hash reference of filter functions.
=item i18n
L object.
=item iterators
Hash references of iterators.
=item values
Hash reference of values to be used by the process method.
=item auto_iterators
Builds iterators automatically from values.
=item autodetect
A configuration option. It should be an hashref with a key C
and a value with an arrayref with a list of B for objects
which should be considered plain hashrefs instead. Example:
my $flute = Template::Flute->new(....
autodetect => { disable => [qw/My::Object/] },
....
);
Doing so, if you pass a value holding a C object, and you have a specification with something like this:
The value will be C<$object->{method}>, not C<$object->$method>.
The object is checked with C.
Classical example: C.
=item uri
Base URI for your template. This adjusts the links in the HTML tags
C, C, C, C and C