in reply to Re^3: Moving A Template Module Namespace
in thread Moving A Template Module Namespace

The development version that will be out hopefully next week, has compartmentalized all of the roles into separate files. It also includes the ability to compile to straight perl code. If you have a compiled perl template then you don't need to load the parsing and compiling modules so it will be much faster.

It will also still support the non-perl compiling method which was one of its claims to fame previously. Now you can have a two stage compile: 1) on the first hit, compile to AST and play directly off of the AST. 2) on the second hit use the AST to compile perlcode and use it. The first hit on all of the various template engines is slow because they are compiling to perl. The new method splits it up, and only gives you a compiled perl document if you need it (because you got two or more hits - or you told it to always generate compiled perl).

Again - the benefit is that it supports Template::Toolkit v2 and v3, Text::Tmpl, HTML::Template, HTML::Template::Expr, and will soon have Velocity support. It also extends all of the types (except HTML::Template which is intentionally kept purist) to include the features from each of the other mini-languages. And all of the various syntaxes compile to the same AST and ultimately to the same Perl code. All of the templates syntaxes can be used from each of the others. I'll probably add support for picking syntax by file extension. That should give pretty good ease of use.

Even with a complete compiled-perl solution you will always need a little bit of base module. The base module needs to do the checking for loaded templates, check for compiled caches, and offer chained operator support. It should also provide for loading the other roles when needed. It turns out that that is what my new version of the code does.

I hope to have it out soon.

my @a=qw(random brilliant braindead); print $a[rand(@a)];
  • Comment on Re^4: Moving A Template Module Namespace