Hi!
> Would anyone care to elaborate on the objectives of the template
> system? Will the templates see the light of day on the client-side
> like Radio's templates are exposed? If so, there should be a way for
> designers and content owners see what is going on, correct?
Hmm. At current time I think the biggest value would come out of using
the templates for the programming part of PyCS - to allow Phil and me
and others to easily write up modules with dynamic content and separate
programming and designing. And I think I would like to use them to build
administrative interfaces - the first round will mostly concentrate on
the usual sysadmin stuff.
There might be a second stage when I find a good and easy way to build
Python "sandboxes" to evaluate code, because then I can integrate them
directly into medusa via a template handler - this would enable us to
use template functionality on the server via Radio templates. This would
actually be quite weird, as you would write Radio templates to create
HTML files that use Cheetah template code to evaluate on the server. It
would be quite cool, as it would break one limit Radio currently has,
that it only can export static content and has to rely on Javascript and
pulled-in modules for dynamicity. Look at the hacks done for the Radio
Nuggets - that's really cool JavaScript hackery, but it is hackery
nontheless, and would be far easier and stable if not using JavaScript.
(For a stability example: ActiveRenderer doesn't work with Opera on
Linux and some versions of IE - that's always a problem with JavaScript,
the little differences).
To use it on the client side directly, you would have to run something
build in python. So it might be a nice fit for Phil's bzero, where it
could give you the same functionality as the templates in Radio. But
that's up to Phil, as bzero is not open source :-)
bye, Georg
Cool! Thanks for taking the time for writing this up, Georg. Your
insights are appreciated. Your points make things clearer for me.
Would anyone care to elaborate on the objectives of the template
system? Will the templates see the light of day on the client-side
like Radio's templates are exposed? If so, there should be a way for
designers and content owners see what is going on, correct?
I ask these questions because the folks at evectors.it have a little
Radio tool that evaluates the Radio template and provides a way of
editing a template in a WYSIWYG editor. I wondering, out loud, what
would be involved in doing the same thing using Cheetah's Template
language. It will be interesting to see Phil's GUI and how this will
all mesh together.
Regards,
Robert
On Friday, Dec 13, 2002, at 07:21 US/Central, Georg Bauer wrote:
> 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
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> PyCS-devel mailing list
> PyCS-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pycs-devel
