Cliff Wells wrote: > That's not the point. The software is poorly thought out and this is a > merely a single symptom. TurboGears uses Kid as its default template > system and while most people like it on the surface, about half the > traffic on the list has to do with its shortcomings and frailties. > "Kid templates are a pain to debug" was an especially long thread.
I looked at TurboGears and while it looks great on the outside,
TurboGears itself seems to be a huge monster, starting with the
easy_install stuff ... not s easy at all. For our webserver I'm
planing to use CherryPy, just like TurboGears. For CherryPy, every
page is a function in Python which needs to return a valid HTML
page. For the canvas system I'm thinking of something similar: every
event or change in the skin is a python callback function.
So how to return valid HTML and how to draw the canvas? Here XML kicks
in. For the webserver simply because you need HTML and XML looks
similar. To make it easier, the canvas system should also use
XML. Since both the canvas and the webserver need some programming
logic inside XML. I agree that Kid does not look pretty, but it does
the job. Yes, we could greate our own template engine, just like we
coded our own config system some weeks ago, but we don't have the man
power to do that. If you look at SVN checkins, all checkins are from
me or Jason. Rob and Soenke are very busy right now doing ather stuff
and that's it. We don't have the resources to code everything
ourself.
> You miss the point. It is Python-based markup vs XML-based markup that
> I'm arguing for.
Well, XML is a markup language, Python is not.
> Show me the designer who can't see the correlation between:
>
> html [
> head [
> title [ 'foo' ]
> ],
>
> body [
> div [ 'bar' ]
> ]
> ]
>
> and
>
> <html>
> <head>
> <title>foo</title>
> </head>
> <body>
> bar
> </body>
> </html>
I guess they see the correlation, but the second is more familiar.
> Also, show me the designer who understands:
>
> <table>
> <tr py:for="row in somelist">
> <td py:for="image in row" align="center">
> </td>
> </tr>
> </table>
>
> and I'll show you a designer who could have grasped Stan or XIST far
> easier.
We won't do that much in the xml file anyway. Basicly we will need Kid
for some 'if' statements in the code, similar to the current skin
files. The logic itself (how to draw a listing) will be done in pure
Python. And while it looks also scary to me, so does php and designers
seem to be happy with that.
> It's a fallacy that XML based templates are easier to grasp for
> *anybody*, let alone designers. Designers don't understand *programming
> logic*. Syntax has nothing to do with it. It has nothing to do with
> whether the tags are enclosed in <> or {}. If the markup requires logic
> you are out of their realm, so trying to appeal to them by using
> convoluted markup mashed with code is a waste.
I'm open for suggestions. I need an easy way to describe skins and
webpages. Both should be the same language and I don't have the time
to develop a huge template module like Kid and far not enough time to
design a language itself. Like in the posts shown before, I only need
some 'if' statements inside the description language, so XML + Kid
seems a good and fast way to do that.
Dischi
--
Symbol's function definition is void: signature
pgpGde3YosvRi.pgp
Description: PGP signature
