On Wed, Jun 13, 2001 at 09:32:25AM +0200, Jonas Liljegren wrote:
> Because; TT is specially adapted for templates. It provides
> constructs designed for use in templates. A language for another or a
> more general problem-space can't be as adapted as a language specially
> designed for templating.
Jonas hits the nail right on the head.
The Template Toolkit implements a "presentation language", not a
"programming language".
Just as SQL is a domain specific language for retrieving data from
databases, and XML is a domain specific language for flexible text
markup, etc., etc, the Template Toolkit implements a language for
abstracting data (hiding the implementation details), presenting it
efficiently, and generally gluing content together quickly and painlessly.
Perl is a programming language. We like Perl. We like Perl a lot. We
want to write our programs in Perl.
But for generating content, there are other languages that are better
tailored to the job. There's even a small template language built in
to Perl itself: formats! And regular expressions - they're a domain
specific language all unto themselves. DSL's are useful. They allow
us to express our intentions (i.e. get the job done) in a manner which
is much more closely aligned to the task at hand.
In Perl, it's important to know the differences between scalars, lists,
objects, references and so on. When we're programming, we want a language
that has maximum flexibility in allowing us to build our programs just
how we want them.
When it comes to presenting data, we don't want to know if it's a hash,
array, object, or subroutine, it shouldn't matter if the data is generated
up front or on demand and we generally don't want to worry about getting
all the $syntax->{ exactly }->right(). We just want a bit of text to
insert in the template and we don't care where it comes from. We want
to say [% INCLUDE user/info FOREACH user = myorg.users %] and have a
parser work out on our behalf how best to rewrite that in Perl, with
caching, error handling, lazy iteration (if necessary) and so on.
This is not dumbed-down programming. It is very smart programming.
It achieves a high separation of concerns. It makes our lives easy
and less tedious. This is a Good Thing.
So with that perspective, re-read the excert as:
> This approach has two problems: First, their little language
> is crippled. If you need to do something the author hasn't
> thought of, you lose. Second: Who wants to learn another
> language? You already know Perl, so why not use it?
This approach has two benefits: First, our little language
is crippled. It's design to be that way. It's not a full
blown programming language so it can be a lot simpler and
more highly adapated to the task at hand: presentation.
If you need to do something the author hasn't thought of,
you win. You can write your code in Perl (or C, C++, etc)
and simply make it available in your templates as a template
variable, a plugin or a language extension. You can reuse all
your existing code, and all the hundreds of existing Perl modules
available from CPAN. Best of all is that you don't need to embed
your Perl code in your templates, you can keep it in a separate
place so that it's easier to maintain. Second: Who wants to learn
another language? Well, if you already know Perl then you can
carry on using it for programming. The Template Toolkit language
is grossly simplified compared to Perl so you shouldn't have any
trouble picking it up. If you don't already know Perl, then this
should be much easier to get a grasp on.
Hmm, maybe not quite as succint :-)=
A
--
Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated.
<[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
