Re: Templating engine?

From: Paramjit Oberoi (p_s_oberoi_at_hotmail.com)
Date: 06/21/04 

Date: Mon, 21 Jun 2004 13:05:19 -0500

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

Relevant Pages

  • Re: Re-use of user interface parts, separation of design and code
    ... First for separation of design and code, TT will kep them in separate files. ... If your page is named for instance "hello", html template for that page will ... The code you write will reside in the file named "hello.logic.php" and it ...
    (comp.lang.php)
  • Re: to template or not
    ... > should separate markup from the progrmaming code, ... If you don't like the looping or conditioning inside the template, ... > nice and usable language/library and a less than perfect template system, ...
    (comp.lang.php)
  • Re: unifying Styles of multiple documents
    ... Proof and Print as separate files, using RD fields to create a combined ... You can unify the styles in the separate documents by creating a template ... Save, Close, and Re-open each document, then turn "Automatically update ... I'm assembling a book from multiple documents with widely diverging ...
    (microsoft.public.mac.office.word)
  • Re: Architecture best practise
    ... template into a string and substitutes values in place of tokens and ... The notion is, apparently, that the UI should be completely separate ... from the code so that HTML designers can specify and amend ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Python vs PHP
    ... it doesn't even have to use any template whatsoever ... > if it doesn't want to, generating HTML from code is the main thrust of ... markup and code, but also that markup reuse is allmost impossible. ...
    (comp.lang.python)