On Nov 15, 1:10am, Sam Tregar wrote:
> Rather, I think that most of the simplicity of HTML::Template comes from
> its strictly "one-way" interface. The template file contains only
> output-oriented structures.
Indeed. Embedded Perl processors are great for embedding Perl in your
web documents. A Template processing system (by my definition) is
something that uses generic templates as particular views on underlying
data. The information system should modify and manage the data, the
templates should just define what it looks like to the outside world.
> Input can only come from the perl side. I
> think that much of the "slippery slope" refered to previously comes from
> allowing the template file to perform processing of its own - to set
> variables and call procedures, for example.
Yes, in an ideal world you don't want to do any real work inside the
template. It is a view, not a model or controller. That's what we
call interface abstraction - keep the "what it looks like" away from the
"what it is". Then you can change what something looks like without
touching what it is. Or you can change how something works without
changing what it looks like.
Making this actually happen if the hard part. This is a whole research
area unto itself. Don't trust anyone who tells you they have all the
answers.
> Hmmmm... Shouldn't someone be suggesting a grand-unified templating system
> right about now? Or maybe we're finally beyond that? I hope so! The
> truth of the matter is that there is no one ultimate way to tackle
> generating HTML from Perl.
Yep, there are plenty of ways to generate HTML from Perl. Very few of them
are really generic Template processors. The benefit of having one universal
system is that people can then start writing web applications that can
be shared easily from one site to another. Download someone's chat module,
munge the templates around a bit until they've got your own look and
feel, and you're done.
You can't do that when people use 24 different template processors.
> The only question I'm really itching to answer is which template system is
> fastest?
When I was writing the Template Toolkit, I spent a lot of time (months!)
looking at the parser and trying to get it as fast as possible whilst
maintaining maintainability. The solution that stood out above all the
others was to use a "real" parser (LALR(1)). This allows me to write the
template language using a Yacc compatible grammar which is then compiled
using Parse::Yapp. I use Perl regexen to pre-tokenise the text (very fast)
and then feed them into a tight DFA loop which is also rather nifty,
especially when compared to the alternatives.
For more complex langauges, you cannot beat this approach. Text::MetaText,
the predecessor to TT, used a regex based parser (rather than a regex
based tokeniser with a FSM parser). It works fine for simple languages,
but falls apart once the complexity of the language starts to increase
(as it inevitably does). I didn't really benchmark Text::MetaText against
Template Toolkit properly, but a few contrived examples showed something like
an order of magnitude improvement in TT.
The other benefit of using a YACC compatible grammar is that you can
easily convert the parser to a C-based equivalent if you're really concerned
about parsing speed.
The parser is by far the slowest part of a Template processor. Cache
the parsed documents in their intermediate forms and you will save
yourself an awful lot of time. So I guess it doesn't really make and
sense to say which is the "fastest" unless you can compare like-for-like.
And it's not really fair on the caching processors to turn their caches
off so that they run as slowly as all the others just to get a "fair
comparison".
A
--
Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated.
<[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
