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