> Here's something of a brain dump on how it (works/will work) in TT3.
>
> In TT3, all templates are instances of Template::Template (hereafer T::T).
> Or rather, they're instances of subclasses of T::T which specialise it for
> different languages:
>
> Template::Template::TT2
> Template::Template::TT3
> Template::Template::HT (HTML Template)
> ...etc...
>
> I hadn't considered Velocity or Text::Tmpl until now. But seeing as you've
> done all the hard work, I guess we can add them to the official list. I've
> also got PETAL pencilled in as something that would be nice to support.
There is also PHP's Smarty and Python's Cheetah that aren't too far off -- so
long as the template designer leaves code out of the template and just uses
the templates mini-language features.
I've also noticed that with a little bit of work, the Alloy parser could be
made to understand ECMAScript. The TT syntax is already fairly close to
javascript in relation to data access. TT has the underlying DIRECTIVES that
would be the same at ECMAScript builtins (IF/if, MACRO/function, WHERE/where,
FOR/for, BREAK/break, and so on). Data access just needs to add foo[bar]
where we currently can use foo.$bar or foo.${ bar }.
> $t->uri()
> [aside]
> The uri() method is worth mentioning because it ties in with another
Sounds like a neat feature.
> The outer template passes a reference to itself as the 'context' for the
> inner template. The inner get() method can then call the $context->get()
> method to fetch any variables from the outer template and cache them
> locally. Although that first get() on a variable takes a shade longer, the
> local cache means you only take the hit once. And you win by only doing
> this for the variables you actually use, whereas the current stash cloning
> code copies all your variables, every time, regardless.
I really - really like this. This is very similar to how Perl 6 works with
its scoping and searching for variable names that apply to the current scope.
> Anyway it's certainly very inspiring for me to see a working implementation
> of these ideas in CET/Alloy. It's serving as both the carrot and the stick
> that's keeping me moving forwards on TT3.
Well - my long term goal for Template::Alloy is to mark it as deprecated when
TT3 is finally there - or at the very least to mark Template::Alloy as a
subclass of Template. I'll maintain Template::Alloy as long as necessary,
but it isn't really my main focus. But it is currently filling in a void
where I work - and I hope that it is giving ideas and benchmarks to play TT3
against.
> I've got a shiny new version of the TT2 web site and an overhaul of all the
> documentation that I'm about to push out. The very next task on my TODO
> list is to set up a public subversion repository for the TT3 code so you
> can get your hands on what I've got. However, I'm interspersing that with
> Real Work[tm] for the next few months so I'll be dropping in and out a bit.
Looking forward to it.
I have a further proposal that I didn't really think should be in a separate
proposal email as it is a rather fundamental change to TT. I would highly
suggest using the intermediate AST (abstract syntax tree). I'm not
necessarily advocating Alloy's AST as I think there are failings for a
general purpose AST - even though it is more than suitable for a Template
AST. The reason for using the intermediate - is that the intermediate can be
shared with JavaScript or other programming languages. It also can be turned
into Perl 5 code (such as what Template::Alloy::Compile) does - or it can be
turned into Perl 5 Template::Documents (such as what Template::Parser::CET)
does. There is no reason that the raw data could also be turned into Parrot
AST, or Perl 6.
Another reason for using the AST model is that I have found that compiled Perl
5 code only beats AST if you are running in a mod_perl environment. In a
situation where you have to read from file cache, or if you have to compile
fresh (such as from a string ref) every time - then running off the AST is
faster as you can skip the intermediate code generation/evaulation step.
For some documentation about this there is:
http://search.cpan.org/~rhandom/Template-Alloy-1.002/samples/benchmark/bench_various_templaters.pl
http://tinyurl.com/22pwrq
The interesting thing isn't necessarily how Template::Alloy (TA in the URL)
relates to other modules - but how it relates to itself. The case in point
in this discussion is TA vs TA_P, or TA_X vs TA_XP on the file cache tests.
TA is Template::Alloy - pure perl running off AST.
TA_P is Template::Alloy - pure perl running off compiled perl code.
TA_X and TA_XP are similar to before - but using XS to do the variable
lookups.
The pure perl AST is 92% faster than loading the compiled perl. The XS AST is
127% faster than the compiled perl version.
Of course if you move to mod_perl the compiled_perl version is 44% faster than
the AST under XS and 22% faster than AST under pure perl. The nice thing
with the compiled_perl version running under XS is that it is as fast as any
other templating option available on perl.
Obviously the benchmarks would change depending upon the template used - but I
think it represents a good comparison of the different implementations.
A final reason for using the AST is that you can then avoid having to store
perl written by the Apache server. Many people view this as a security issue
with Template. My suggested setup for Alloy is to only use compile_perl if
you are in a cached environment (such as mod_perl) and to only use
compile_perl if you aren't caching out to file system. The AST is plenty
fast for all other cases. Alloy also offers two stage compilation - on the
first hit you get AST, but on the second hit to the same document in a cached
object you get compiled perl. I'd love to see this in TT3.
Well, I've rambled.
I am really looking forward to TT3 - almost as much as I'm looking forward to
Perl 6. I hope that Alloy will be a good mark for TT3 to aim for in terms of
speed and "lightness." I'll be sure to keep Alloy in line with your
proposals so that I will eventually be able to deprecate Alloy in favor of
TT3.
Thanks again for Template::Toolkit.
Paul
_______________________________________________
templates mailing list
[email protected]
http://lists.template-toolkit.org/mailman/listinfo/templates
