Templating engine?

[has]

Paramjit Oberoi <p_s_oberoi at hotmail.com> wrote in message news:<pan.2004.06.21.18.05.17.475886 at hotmail.com>...

> > - The advantage of separating the two is very designer-friendly markup
> > and complete freedom in how you design and implement the logic. (i.e.
> > easier maintainance)
> 
> You are right: there are three pieces to be managed (1)application logic,
> (2)presentation logic, and (3)markup.  MY understanding of HTMLTemplate is
> that it enforces the separation of markup and all logic (both presentation
> and application), which is certainly very designer friendly.
> 
> The problem is that:
> 
> (1)presentation logic is often trivial, which means it is often not
> separated from application logic.

As with desktop application development, it's up to the developer to
separate/not separate the View's Controller from the Model layer.
Nobody's forcing them to combine the two. I think you're worrying
unnecessarily - folk developing desktop apps seem to manage just fine.


> (2)markup and presentation logic are often quite closely coupled (i.e.
> significant changes to the markup often require changes to the
> presentation logic), but they are in different places

Having the HTML and code in different places isn't in itself a bad
thing. There is coupling between the two, but it doesn't have to be as
tight as it is in macro-style systems.


> (and even worse, the
> presentation logic may even be mixed with the application logic).

Again, if the programmer wants to write spaghetti then that's their
choice. Not my place to dictate/save them from themselves.


> 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. 

I can work on the HTML using all my favourite standard HTML tools, and
the code using all my favourite standard Python tools. I can deal with
each half individually without having the other getting in my way and
spoiling my view. I can hash around the HTML as much as I like with,
at most, minimal breakage - the only stuff in the HTML to break is the
name bindings that tie it to the Controller code, and those are
quickly and easily replaced. The API is very small and simple. How I
structure my code is not dictated by the structure of my template. The
implementation can be as granular as you like, so should be easy to
test and profile right down to the atomic level. I can hand the HTML
half to one developer to take care of and the code half to another.


> Ideally all three, application logic, presentation logic, and markup would
> be separate, but I think it's more important to separate application logic
> from presentation+markup than markup from application+presentation.

DOM-style templating engines provide the three-way separation you
describe.


> But, my views are also colored by the fact that I've never dealt with
> large and complicated templates.  In that case it would probably be a good
> idea to separate the template from presentation code just to keep the
> complexity under control. 

You can find an example of complex use (~100-line template, ~200 LOC)
in the appscript project on my site. See the
appscript.htmldoc.Renderer module. And yes, the clear separation of
code from markup really comes into its own. Mind you, I find it quite
pleasant in simple use too even though the heavy decoupling tends to
make it a little more verbose than equivalent TAL/Cheetah code.

> >> Cheetah-like systems are much more flexible (and simple
> >> substitution-only templates are very limiting).
> > 
> > DOM-style templating systems aren't 'substitution-only', and can
> > easily match or surpass macro-style systems for power and flexibility
> > at a fraction of the size and complexity.
> 
> 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.
Editing the business logic is modifying the program too. DOM-style
templating systems allow you to work on the first and/or second
without touching the first, just as macro-style systems do.


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. The popularity
of BDSM languages like Java would indicate there's plenty of folk
around who like working within restrictive tools and environments. I
come from the other school of thought - the one that says that tools
should be small, simple, extensible and as free of built-in
limitations as possible, and assumes the developer is smart enough to
make their own informed decisions as to how they use them. The
popularity of highly dynamic languages from Python and Perl right back
to Lisp suggests there's also plenty of folk who prefer extremely
flexible, malleable tools. But this is a different debate


Anyway, if you want to compare DOM-style templating systems to
something else, try a modern desktop GUI development system such as OS
X's AppKit framework + Interface Builder. They're far closer
conceptually to this type of system than to PHP et-al, which have
their roots in command line macro pre-processors, and it might help
you see where they're coming from a bit better.

HTH

has