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

I've had just a quick glance at the module. Apparently it has over 3300 lines of code (including docs, interspersed between the code) and it takes up more than 120kBytes. That's quite a lot, especially for a "lightweight" templating module.

What I was hoping for, is something that (AFAIK) TT2 does provide, and that is preprocessing a template file and turn it into a plain Perl source file, and save that to disk. The template is actually converted into a Perl module. That way, when the template doesn't change, the templating module doesn't even have to be loaded into memory, and output generation can happen at full speed. That sounds like the most promising approach for CGI applications, to me, as it is lightweight, and templates don't change too often.

So... what is your opinions on these thoughts? Did I miss something, or did you think about it and found it was just not worth the trouble, or... ?

  • Comment on Re^3: Moving A Template Module Namespace

Replies are listed 'Best First'.
Re^4: Moving A Template Module Namespace
by Rhandom (Curate) on Jun 01, 2007 at 15:13 UTC
    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)];
[reply]

In Section Meditations