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
On Friday, Dec 13, 2002, at 04:25 US/Central, Georg Bauer wrote:
> Does the non-existence of replies say you all don't care, you all
> object
> or you all agree? :-)
>
> I really would like to get some feedback, because using Cheetah would
> add
> to the prerequisites of PyCS. So even if you don't care, please just
> say
> that you don't care, so I know about it.
Sorry, Georg for not replying to the list....
From a neophyte's perspective Cheetah appears to be something I could
handle. I looked over the User's guide and it appears to be a pretty
straight forward. I would be interested to learn how it would interact
with tools like Mozilla's Editor, Dreamweaver or GoLive. Having the
capability of extending these tools to handle template design and
modification would be idea for the whole PyCS design and development
process.
Regards,
Robert
Hi!
> How about using it to make whatever you're planning at the moment (admin
> pages?) but leaving the existing pages as they are for the moment? That
> way we can see what it's like to use, and (if necessary) back out /
> switch to another system.
The problem is, my first idea is to template the existing pages in the
system modules to become able to switch everything to a real layout from
the rather crude stuff I use now :-)
Admin pages are something that needs to be done, but they are even more
something I have to think about first, to get them right.
bye, Georg
Georg:
> Does the non-existence of replies say you all don't care, you all object
> or you all agree? :-)
>
> I really would like to get some feedback, because using Cheetah would add
> to the prerequisites of PyCS. So even if you don't care, please just say
> that you don't care, so I know about it.
I had a look, and it seems fine to me. Sorry; I thought I'd already replied
:-)
How about using it to make whatever you're planning at the moment (admin
pages?) but leaving the existing pages as they are for the moment? That way
we can see what it's like to use, and (if necessary) back out / switch to
another system.
What were you thinking of doing first?
Cheers,
Phil
Hi!
> I again looked at templating systems for python and stumbled across
> Cheetah, the templatingsystem behind webware. This can easily be used
...
> http://www.cheetahtemplate.org/
Does the non-existence of replies say you all don't care, you all object
or you all agree? :-)
I really would like to get some feedback, because using Cheetah would add
to the prerequisites of PyCS. So even if you don't care, please just say
that you don't care, so I know about it.
bye, Georg
