Terrence Brannon <[EMAIL PROTECTED]> wrote:
>
> 2. why do we need a template *language*. What is it about templating
> that requires a new *language*? Templating entails a few simple
> operations that can be handled in any general purpose language - LISP,
> Perl, Python, C, C++.
the evolution of everybody's template system starts with the very simple
non-language need to store some text (or HTML) in a separate file (from
one's code) that can later be easily modified by a user, i.e. the text:
dear $foo,
your account balance of $overdue_balance is now overdue. please
remit payment in full before $shut_off_date, to avoid termination
of your services.
if you have mailed your payment in the last 7 days please disregard
this notice. thank you.
the simple scalar replacements need little "markup" to be
search-and-replaceable by perl, and it is much more elegant to have this
text reside somewhere *outside* of the perl code. of course, each template
system to date has it's own way to delimit these scalar replacement tokens.
but as each author in turn must learn, scalar replacements are never enough.
not for long. they lead to harder templates. you soon need way to declare
*conditional* blocks of text:
<if $recent_payment_amount>
Your recent payment of $recent_payment_amount was appreciated, but
annoyingly insufficient.
</endif>
this is usually followed by some sort of if/then construct:
<if is_good_customer>
This is just a friendly reminder that your payment is overdue.
Please remit as soon as is convenient.
<else>
if payment is not received in this office by $shut_off_date, your
account will be deactivated and the balance turned over to our
collections department, who will harass you and ruin your credit.
</endif>
or even (god forbid) a case/switch! (example omitted)
finally each template system must account for rows of repeating data
suitable for dynamically assembling lists of links, rows in a table,
products in a shopping cart, or what-have-you:
<repeat invoice_item>
$item_id | $item_name | $item_cost | $item_qty | $item_total
</repeat>
while this is statisfyingly powerful, and simple enough even for
non-programmers to add, it too leads to template-as-language addiction, when
the brain-rush resulting from the taste of power corrupts the normal,
keep-it-simple sensibilities of the programmer:
<repeat invoice_item type="greenbar_report">
<if test="__ROW_NUM__" assert="IS_ODD" set="row_color" value="green">
<else set="row_color" value="white">
$item_id | $item_name | $item_cost | $item_qty | $item_total
</repeat>
or worse, the embedded expression evaluation:
<if $customer_type eq 'individual'><if $overdue_balance lt 100 >
here is where we realize that we have run amok and the thing we originally
created to empower our non-programmer users to simply modify a bit of output
text (the bit that was inconsequential to the program) has become yet
another programming language in and of itself, again, inaccessible to
non-programmer users.
if you have any doubt that any sufficiently advanced template systems is
indistinguishable from a programming language, take a closer look at ASP,
PHP, and CFML.
-dave
