Web templating/db tool with best designer/coder separation?

[Stefan Franke]

On 22 Jun 2002 18:43:50 GMT, bokr at oz.net (Bengt Richter) wrote:

>E.g., if you were hoping for an improvement over current practice,
>which do you consider to be the tool(s) to beat, and what would
>the killer improvement(s) be? TIA.

[... and later]

> Opinions on ZPT?

I have a (vague) idea I'd like to discuss in this context. The first 
thing that came to my mind while reading the ZPT/TAL announcement 
some  time ago was this:

It's a brilliant idea to use attributes to specify operations on their
including tags (replacement being the most important operation). 
Using special attributes instead of special tags increases the
propability that they're left unchanged by HTML editors. 

But does it really go far enough? Still, the presentation logic
substitution, iteration, ..) is encoded within a HTML template file
with (now semantical, not syntactical) non-standard elements, which 
makes it hard to hand out the file to a page designer who 
knows nothing about programming.

Can we further reduce the 'degree of intrusiveness'? (excuse my clumsy
english) The set of operations we want to perform on a template is 
clear (see TAL spec): replacement (of tags or tag content), iteration,
conditionals, adding attributes etc. 
But why place these operations inside the tags/template instead of 
finding another way of specifying the affected tags?

HTML offers a standard way to address tags by using id attributes. 
Can't we leave the HTML alone, just mark the affected tags by giving
them IDs, and put all the replacement/iteration commands into a 
separate place?

The presentation commands could be either ordinary Python statements 
or some abbreviated/specialized variants of it (e.g. Quixote-like).

The advantages I see here are

- The template document is perfect HTML. Since we have substitution
  commands like in TAL, we can fill up the document with dummy data
  and make the template itself appear well-formed and reasonable
  in any browser

- All the HTML designer has to respect are the IDs of certain tags 
  ("tableLine",  "customerNameCell", ..). If he knows JavaScript/DHTML
  he should be familiar with this anyway.

- The same replacement logic could be applied to different template 
  files, we have an additional layer of indirection here.
  
- One presentation command file could address and assemle 
  elements from different  HTML template files


Disadvantages:

- One has to maintain two documents instead of one (but as I argued, I
  see this as an advantage)

- In case of conditionals, there might be difficulties to bear up the 
  rule  that the template file is always perfect visible HTML - at 
  least without redundancy

- Scoping/local replacement within iteration might become complicated

 * * *
 
What do you think about it? There might well be big things I 
left out of consideration, since I'm quite out of web business (my
last bigger project was with Zope 1.10.2 and its DTML...).

Best,
Stefan Franke