Ow. That philosophy of 'make it impossible for the programmer to mess up' sounds
too reminiscent of Pascal and other straightjacket development environments. I
don't think there's any real substitute for well-disciplined, thinking
programmers. So my own quest right now is to develop more of the right
disciplines, rather continue on some quest for a mythical Template System to End
All Template Systems or whatever.

For example, you mentioned you don't like objects in templates because they
introduce complexity. But others have already pointed out that objects can be
used in templates as simple read-only accessors by HTML designers who don't need
to know how the object is implemented. That's the great thing about
encapsulation. Sure this feature could be abused, but I'd rather err on the side
of freedom.

--Wes



Sam Tregar <[EMAIL PROTECTED]> on 06/05/2002 06:45:34 PM

To:   Andy Wardley <[EMAIL PROTECTED]>
cc:   modperl List <[EMAIL PROTECTED]>, Template
      Toolkit List <[EMAIL PROTECTED]> (bcc:
      Wesley Sheldahl/Lex/Lexmark)
Subject:  Re: Separating Aspects (Re: separating C from V in MVC)



Here's my theory: the best usage of most templating systems are virtually
indistinguishable and all result in reasonably maintainable systems.
However, the bad usage of some templating systems is much worse than
others.  Also, the general usage of a templating system, even by otherwise
bright people, tends more towards the bad than the good.

Thus my solution: a templating system that simply will not allow you to
put anything significantly complicated in the template.  You can't.  If
you want complexity you'll just have to put it in the code, where it
belongs.  That's HTML::Template in a nutshell.

>   [% silver.bullet %] isn't the answer by itself...

Here here.  Neither is <tmpl_var silver_bullet> but I'd rather get shot
with mine than yours!

-sam



Reply via email to