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

[Robert B. <rba...@ma...>]

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
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pycs-devel