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

[Ian Bicking]

On Mon, 2002-06-24 at 19:36, Bengt Richter wrote:
> On 22 Jun 2002 18:43:50 GMT, bokr at oz.net (Bengt Richter) wrote:
> and from the description, this would seem to have a real advantage over all of
> the above, in that it uses attributes of html tags as opposed to special tags
> that browsers or design tools won't generally understand and render usefully.

Cheetah avoids using these tags for this reason.  It still requires
invalid HTML for some cases, though, particularly:

<table>
#for $item in $list #
<tr><td>$item</td></tr>
#end for #
</table>

(Note that you can use # to end statements, as you should do if you want
the template to work in WYSIWYG tools, which won't preserve newlines)

There's ideas for fixing this, but it's very annoying from the parsing
perspective... right now Cheetah doesn't have to understand markup at
all, but anything that will fix this will likely have to parse the
markup in order to work well.

In most other cases, though, I think Cheetah will be more usable if you
want to expose programming logic to designers.  I personally don't feel
that designers should be insulated from the logic -- it is essential to
know, for instance, that something will be repeating, or exactly what
variable gets inserted where.  Using dummy information to express this
isn't, IMHO, as transparent or reliable (since the dummy information
isn't necessarily in sync with the programming code).  

But this depends on how you view the designer, and what you expect of
them.  If you want the designer to be able to code the template, I don't
know how well ZPT will do -- it doesn't seem like an intuitive way to
think of the template (though I would expect a programmer to adapt
easily enough).  If you want the designer to only edit documents that
are first created by programmers, then it might work well.

But this is only my intuition, I haven't actually tried to use Cheetah
or ZPT with designers like this.


You might be interested to look at XMLC (http://xmlc.enhydra.org/) --
similar to ZPT, but with greater WYSIWYG support, and with considerably
less transparency (no actual code is contained in the template).  It's
kind of the extreme of that direction -- like accessing a DOM where the
markup is annotated and the API is much more friendly.  It's not in
Python, though maybe someone has created a clone (which shouldn't be
hard).

> BTW, which is the most appropriate Python version to assume everyone's servers
> will be converging on? 1.5, 2.1, 2.2, or ? Could I reasonably plan on using 2.2?
> E.g., I think 2.1 is being included in most newer linux distributions. But more
> to the point, what version will most likely be available via server cgi etc.?
> I'd like the answer to be 2.2 ;-)

Servers tend not to be very up-to-date.  I think 1.5.2 is still quite
common -- at least, it's likely to be /usr/bin/python on lots and lots
of servers (even if python2 is available somewhere).

  Ian