Re: [PyCS-devel] RFC: templating system proposal

[Georg B. <gb...@mu...>]

Hi!

> straight forward.  I would be interested to learn how it would interact
> with tools like Mozilla's Editor, Dreamweaver or GoLive.  Having the

It is mostly ignorant of those tools, but won't break too much. There are
several ideas on integrating Script with HTML:

1) invent your own tags (DTML)

This has the problem that most GUI tools don't support those and so they
are a PITA to use. You are usually forced to switch to HTML source view.
And without clear visual distinction between html and script, code often
is hard to read. Syntax coloring editors can sometimes help by coloring
script tags differently from standard tags, but it is not often
implemented.

2) invent your own attributes and use existing tags (ZPT)

These are more resistent to GUI tools, as they usually just fit in if the
tool supports user defined attributes to tags (like Dreamweaver does). If
your GUI tool doesn't support user defined attributes, and possibly
rewrites code to it's own likening, you are doomed. And another problem:
since you have to put your attributes in available tags, you are forced to
build your script in the same structure as your HTML. This sucks for
bigger tasks. It does allow you to do nice "example" coding and later
overwriting automatically your example data with real data, though -
that's the one big advantage of ZPT. Distinction of html and script is
even worse than with number 1. And syntax coloring editors usually get
lost, as they don't know which attributes to color this way and another
way.

3) use ASP taglike structures (many do that, you recognize them by <% %>)

The same problems as with defining your own tags, as most GUI tools
process ASP tags as some obscure tags. Often they reformat stuff and it
breaks, especially if your stuff is whitespace sensitive. But the nice
thing is that if your template language is compatible with ASP, you might
find tools that support it natively. Visual distinction of html and script
is better, but since the script looks much like html comments, it might
get bad if you comment heavily. But syntax coloring editors can help a lot
here.

4) invent your own language (like almost the rest does)

This has the big drawback that you have to learn the language. But it has
the big adavantage that you can design your language near enough to a real
language. Cheetah designs it's language conceptually (not in syntax, but
in semantic) like Python. So it can compile templates directly to python
and mix Python classes and Template classes freely. The big advantage of
inventing your own language is, you can design the language in the way
that you need, not anything forced by structures outside the programming
domain. And usually you see your sourcecode in the GUI tool as simple
textual content, this helps with debugging. But there will always be some
(sometimes obscure) areas where the script language will break GUI tool
usage. Often you can get around that problem, but sometimes it's quite
hard to see a way and you have to go back to the source code. Visual
distinction of html and script is often quite good, as script looks very
differently than script code is regarded as simple text, so stands out
even in GUI tools.

So if GUI tool interoperability is highest priority, an approach like ZPT
would be best. If programming is hightes priority (and since that is what
I do most of my daylife ;-) ) you have to go for something like Cheetah,
as you get a full fledged language that is easily integrated with the
server software. Programmers usually use more syntax coloring editors than
GUI editors.

I prefer the programmer approach :-)

bye, Georg