Templating engine?

[has]

Paramjit Oberoi <p_s_oberoi at hotmail.com> wrote in message news:<pan.2004.06.22.14.59.52.138809 at hotmail.com>...
> >> The second point above is why I don't understand your claim that the
> >> separation of presentation logic and markup would be easier to maintain. 

[snip list of arguments]

> OK, pretty good arguments.  I see the point.  I guess I would see it more
> strongly if my favourite tool for editing both HTML and python wasn't a
> standard text editor <0.5 wink>.

Only my first argument related to authoring tools; the rest are
general design and management issues.

BTW, my favourite HTML and Python editing tools are also simple text
editors, and I still find the separation of markup and code
advantageous. I like being able to wear my "HTML stylist" hat separate
to my "code geek" hat, especially when it comes to editing and
previewing templates, something DOM-style systems are especially good
at.


> >> By flexibility I meant flexibility in what you can do by modifying the
> >> template alone (since presentation logic can be added to the template).
> >> In the case of 'DOM-style' systems you may have to edit the template as
> >> well as the presentation logic (which would mean modifying the
> >> 'program', not just the template).
> > 
> > You're making a false distinction here. The template and the
> > presentation logic are as much a part of the "program" as the business
> > layer they sit on top of. Editing the template markup is modifying the
> > application. Editing the template logic is modifying the program.
> 
> I think it is a very real distinction.  If you are a user of the
> application, you don't want to have to maintain a private set of
> modifications to it.  Also, the application might be installed in a
> read-only location...  It might even be compiled, once all the python
> compilers really take off.

I see no difference between having an application that loads up a
folderful of Cheetah templates, and having an application that loads
up a folderful of PyMeld/Nevow.renderer/HTMLTemplate templates. You're
seeing barriers where there aren't any; monolithic construction where
there's no need for it. It's completely up to the developer where they
want to put the joins in the system, which bits they want to decouple
from the rest of the system and expose to outsiders, and which they
want to lock away in the application core. Which is just how things
should be, and DOM-style templating systems certainly don't interfere
with it.

(Mind, I've thrown away thousands of lines of working code - including
complete templating engines - precisely because it imposed the sorts
of stupid artificial divisions that made them frustratingly inflexible
and inextensible, so haven't arrived at the DOM-like design by
accident.:)


> > Now, if you believe that it's the templating system's job to impose
> > and enforce a certain kind of architecture upon the developer - one
> > that makes it impossible to mix presentation and business logic
> > together - then you can certainly make that argument.
> 
> Not at all.  In fact, it's the HTMLTemplate-like systms that enforce the
> separation of markup from all code. 

There's nothing to stop you inlining chunks of HTML in your Python
code, or adding a preprocessor to the system that extracts chunks of
code out of your HTML template and assembles them into a controller.


> With Cheetah you can have as little or as much code in the template as you want

Not exactly true, as it's impossible to have _no_ code in a Cheetah
template. At minimum you'll always have basic flow control and
assignments. DOM-style templating systems start from a much lower
complexity baseline and let you build upward as you want. (See Lisp
philosophy.)

Hope that clarifies.