Web templating/db tool with best designer/coder separation?
Stefan Franke
franke at ableton.com
Tue Jul 2 08:09:11 EDT 2002
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
More information about the Python-list
mailing list