Template-Alloy-1.020

NAME

DESCRIPTION

The Template::Alloy::TT role provides the syntax and the interface for Template::Toolkit version 1, 2, and 3. It also brings many of the features from the various templating systems.

And it is fast.

See the Template::Alloy documentation for configuration and other parameters.

HOW IS Template::Alloy DIFFERENT FROM Template::Toolkit

Alloy uses the same base template syntax and configuration items as TT2, but the internals of Alloy were written from scratch. Additionally much of the planned TT3 syntax is supported as well as most of that of HTML::Template::Expr. The following is a list of some of the ways that the configuration and syntax of Alloy are different from that of TT2. Note: items that are planned to work in TT3 are marked with (TT3).

Note that nested variables are subject to scoping issues. f.b will not be reset to its value before the FOREACH.

Post operative directives can be nested. (TT3)

Andy Wardley calls this side-by-side effect notation.

[% one IF two IF three %]
same as
[% IF three %][% IF two %][% one %][% END %][% END %]
[% a = [[1..3], [5..7]] %][% i FOREACH i = j FOREACH j = a %] # = 123567

Semi-colons on directives in the same tag are optional. (TT3)

[% SET a = 1
GET a
%]
[% FOREACH i = [1 .. 10]
i
END %]

Note: a semi-colon is still required in front of any block directive that can be used as a post-operative directive.

[% 1 IF 0
2 %] # prints 2
[% 1; IF 0
2
END %] # prints 1

Note2: This behavior can be disabled by setting the SEMICOLONS configuration item to a true value. If SEMICOLONS is true, then a SEMICOLON must be set after any directive that isn't followed by a post-operative directive.

CATCH blocks can be empty.

TT2 requires them to contain something.

Added a DUMP directive.

Used for Data::Dumper'ing the passed variable or expression.

[% DUMP a.a %]

Added CONFIG directive.

[% CONFIG
ANYCASE => 1
PRE_CHOMP => '-'
%]

Configuration options can use lowercase names instead of the all uppercase names that TT2 uses.

Added @() and $() and CALL_CONTEXT. Template::Toolkit uses a \concept that Alloy refers to as "smart" context. All function calls or method calls of variables in Template::Toolkit are made in list context. If one item is in the list, it is returned. If two or more items are returned - it returns an arrayref. This "does the right thing" most of the time - but can cause confusion in some cases and is difficult to work around without writing wrappers for the functions or methods in Perl.

Alloy has introduced the CALL_CONTEXT configuration item which defaults to "smart," but can also be set to "list" or "item." List context will always return an arrayref from called functions and methods and will call in list context. Item context will always call in item (scalar) context and will return one item.

The @() and $() operators allow for functions embedded inside to use list and item context (respectively). They are modeled after the corresponding Perl 6 context specifiers. See the Template::Alloy::Operators perldoc and CALL_CONTEXT configuration documentation for more information.

[% array = @( this.get_rows ) %]
[% item = $( this.get_something ) %]

Added ->() MACRO operator.

The ->() operator behaves similarly to the MACRO directive, but can be used to pass functions to map, grep, and sort vmethods.

The RETURN directive can take a variable or expression as a return value. Their are also "return" list, item, and hash vmethods. Return will also return from an enclosing MACRO.

[% a = ->(n){ [1..n].return } %]

Alloy does not generate Perl code.

It generates an "opcode" tree. The opcode tree is an arrayref of scalars and array refs nested as deeply as possible. This "simple" structure could be shared TT implementations in other languages via JSON or YAML. You can optionally enable generating Perl code by setting COMPILE_PERL = 1.

Alloy uses storable for its compiled templates.

If EVAL_PERL is off, Alloy will not eval_string on ANY piece of information.

There is eval_filter and MACRO recursion protection

You can control the nested nature of eval_filter and MACRO recursion using the MAX_EVAL_RECURSE and MAX_MACRO_RECURSE configuration items.

There is no context.

Alloy provides a context object that mimics the Template::Context interface for use by some TT filters, eval perl blocks, views, and plugins.

There is no provider.

Alloy uses the load_template method to get and cache templates.

There is no parser/grammar.

Alloy has its own built-in recursive regex based parser and grammar system.

Alloy can actually be substituted in place of the native Template::Parser and Template::Grammar in TT by using the Template::Parser::Alloy module. This module uses the output of parse_tree to generate a TT style compiled perl document.

The DEBUG directive is more limited.

It only understands DEBUG_DIRS (8) and DEBUG_UNDEF (2).

Alloy has better line information

When debug dirs is on, directives on different lines separated by colons show the line they are on rather than a general line range.

Parse errors actually know what line and character they occurred at.

UNSUPPORTED TT2 CONFIGURATION

LOAD_TEMPLATES

Template::Alloy has its own mechanism for loading and storing compiled templates. TT would use a Template::Provider that would return a Template::Document. The closest thing in Template::Alloy is the load_template method. There is no immediate plan to support the TT behavior.

LOAD_PLUGINS

Template::Alloy uses its own mechanism for loading plugins. TT would use a Template::Plugins object to load plugins requested via the USE directive. The functionality for doing this in Template::Alloy is contained in the list_plugins method and the play_USE method. There is no immediate plan to support the TT behavior.

Full support is offered for the PLUGINS and LOAD_PERL configuration items.

Also note that Template::Alloy only has native support for the Iterator plugin. Any of the other plugins requested will need to provided by installing Template::Toolkit or the appropriate plugin module.

LOAD_FILTERS

Template::Alloy uses its own mechanism for loading filters. TT would use the Template::Filters object to load filters requested via the FILTER directive. The functionality for doing this in Template::Alloy is contained in the list_filters method and the play_expr method.

Full support is offered for the FILTERS configuration item.

TOLERANT

This option is used by the LOAD_TEMPLATES and LOAD_PLUGINS options and is not applicable in Template::Alloy.

SERVICE

Template::Alloy has no concept of service (theoretically the Template::Alloy is the "service").

CONTEXT

Template::Alloy provides its own pseudo context object to plugins, filters, and perl blocks. The Template::Alloy model doesn't really allow for a separate context. Template::Alloy IS the context.

PARSER

Template::Alloy has its own built in parser. The closest similarity is the parse_tree method. The output of parse_tree is an optree that is later run by execute_tree. Alloy provides a backend to the Template::Parser::Alloy module which can be used to replace the default parser when using the standard Template::Toolkit library.

GRAMMAR

Template::Alloy maintains its own grammar. The grammar is defined in the parse_tree method and the callbacks listed in the global $Template::Alloy::Parse::DIRECTIVES hashref.