Wow, look at all these messages! I trundle off the the Perl Conference
for a few days, and come back to an overflowing modperl mailbox.
I'm the author of the Template Toolkit and I figure it's time for me
to give my take on the whole subject. Here's a collection of my
thoughts which hopefully answer some of the questions that have
arisen. Everything is IMHO, of course, but I like to think that I
know what I'm talking about, having spent some considerable time
working on and with such systems in a professional capacity. But
despite what I think, I'm not always right, so please feel free to
take me to task or ask for clarification if there's something that
doesn't fit. I'm always happy to be proven wrong. :-)=
* There are two types of "template" solutions. Those that embed Perl
or another scripting language into the documents and those that
don't. The former include embperl, HTML::Mason, Text::Template,
PHP, ASP, etc. etc. The latter include Template Toolkit,
HTML::Template, and possibly some others (but not many).
HTML::Template offers a sub-set of TT functionality, but it's a
nice, useful and lightweight module that I've used and recommended
myself in the past.
* One of my absolute goals with the Template Toolkit was to get a
clear separation of concerns between presentation, application logic
and data. You can't do this when you embed program fragments into
templates. That's not to say that there aren't times when you might
want to do that, but sooner or later it will severely restrict you
in extending and maintaining your system. You *can* embed Perl
using TT because it's not my job to tell you what you can and can't
do. However, it is disabled by default and not recommended for
building portable systems that are easy to modify and maintain. TT
uses simple dotted compound variables (e.g. foo.bar) to hide the
underlying complexity of a system, and some high-level directives
for gluing template fragments together (INCLUDE, IF, FOREACH,
SWITCH, etc).
* The Template Toolkit started its life as Text::Metatext. It was one
of the first templating modules available from CPAN. It grew and
grew and grew to the point where it had to be thrown away and
re-written from scratch (always plan to throw away the prototype, as
Fred Brooks would say, and trust me, it's good advice). In doing
so, I like to think that I incorporated all the best ideas of the
time, and some more of my own and produced a very generic "pure"
template system that does 99% of what all the others do, and in many
cases, a great deal more (but see the next point). Version 2 is
about to be released and offers many improvements over v1
(particularly speed and efficiency). I'm now confident in calling
it a "mature" product.
* The Template Toolkit is *ONLY* a template system. This is a Good
Thing. It processes text (HTML, Latex, POD, etc). You can use it
under Apache/mod_perl, in stand-alone CGI scripts, or in other
environments entirely unrelated to HTML or the web. This is also a
Good Thing. However, it is ideally suited for building web content,
both dynamic and static (check out 'ttree' which is like 'make' for
building static pages from template components) but it is not a web
application framework. In a nutshell, is it a system for gluing a
front end onto your application, data, or whatever it is that you
want to present. It doesn't concern itself with what you're using
it for, it just makes it very easy to present the output in an
independant manner. If you want a WAF then Iaijutsu/Iaido is one
such system which uses TT (see www.ninjacode.com - I know that Leslie
would *love* some volunteers to help him get it production-ready).
Or use Zope. :-)=
* TT will happily navigate through any kind of complex Perl data
structure you can create. It will traverse arrays, hash arrays,
call code, call object methods, and so on. You don't need to do
anything special to use TT, just pass it a hash array reference to
your data. These are the hooks that allow the TT to use data from,
or make callbacks back into your backend code. This allows you to
use a pipeline model (pre-prepare data, then call TT to display it)
or a callback model (make callbacks from TT to code to calculate/fetch
data/perform processing). Either way, the Perl code is kept out of
the templates.
example:
my $replace = {
foo => {
bar => [ 1, 2, sub { return 'many' } ],
}
}
my $template = Template->new();
$template->process($filename, $replace);
template:
[% FOREACH item = foo.bar %]
- [% item %]
[% END %]
output:
- 1
- 2
- many
* The TT doesn't have any direct support for databases, XML, CGI,
session management, etc., etc. Why? Because there are some
perfectly good modules on CPAN (DBI, CGI, XML::*, Apache::Session,
etc.) that do all this. These are not presentation issues, they are
application functionality and the TT doesn't care itself with them.
TT allows you to write all your application code in Perl, to re-use
existing Perl modules, or do whatever it is that you want to do, and
to keep it *SEPARATE* from the presentation templates. That way you
can create multiple views onto a single application, or change the
application without affecting the views. You can also have
different people doing the coding/HTML design. The HTML designers
don't need to know Perl or anything else too complicated for their
delicate, artistic brains. The "Hard Stuff" is done by the Perl
coders and hidden away in the back end. The "Pretty Stuff" is done
by the HTML designers and hidden away in the front end. Even if
you're the one guy who is both Pretty and Hard, being able to
separate these roles is very useful. Having said all that, TT does
provide a plugin architecture which simplifies the process of
loading external modules so that you don't have to jump through
hoops to get hold of a CGI, DBI, XML, object, etc. e.g.
# load and instantiate a CGI module object
[% USE CGI %]
[% IF CGI.param('debug') %]
The 'debug' CGI parameter was passed to this CGI script....
[% END %]
# ditto for an XML::RSS object
[% USE news = XML::RSS(my_xml_rss_file) %]
[% FOREACH item = news.items %]
<h2>[% item.title %]</h2>
<h3>[% item.date %]</h3>
...
[% END %]
* AxKit is something entirely different, new and icy cool. It's an XML
data engine. I'm hoping to graft TT on to the top of it Real Soon Now.
I've created a mailing list for discussion of AxKit/TT integration
if anyone is interested. See:
http://www.template-toolkit.org/mailman/listinfo/template-axkit
Uhm, I think that's all for now. Hope this answers some question, or
raises some interesting questions. For more info, general mailing lists,
etc., see http://www.template-toolkit.org/ Version 1 is available from
CPAN, while version 2 betas are currently only available from the above
web site. Version 2 beta 2 is 99% stable, and beta 3, due out early next
week, should be rock solid. Once the documentation has caught up with
the code (almost there), I'll be releasing V2 gold and it'll find it's
way onto CPAN.
A
--
Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated.
<[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
