Templating engine?

[Paramjit Oberoi]

> Presentation logic is application code too, regardless of where you
> put it and what language it's written in.
> 
> - The advantage of embedding logic in markup is it's easier for
> non-programmers and other folk who aren't good at/don't like working
> in the abstract to see what's going on. (i.e. easier mental modelling)
> 
> - 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)
> 
> With HTMLTemplate et-al, there's nothing to stop you putting the
> controller code in separate modules to the model code, making it easy
> to edit the former without messing with the latter. (Splitting each
> layer into its own module is probably a good design practice anyway.)

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.

(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 (and even worse, the
presentation logic may even be mixed with the application logic).

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. 
The only advantage I see is that separating the two makes it easier for
designers to work with any tools they want to use.

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.  Also,
presentation logic and markup often just naturally belong together.

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. 

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