Kevin Dangoor wrote:
Kid feels bloated, lots of features which are imho useless and/or costs
too much in terms of performance , most of the time i end up hacking
around kid to avoid its issues. I am one of those who think a template
language has to stay simple (i think it s also django approach).
I'd be interested in examples here. I don't find Kid to be a
particularly complex template system.
In my experience with ZPT I've found it rather difficult for
non-programmers to understand. I think, if anything, that would be more
true for Kid -- ZPT macros aren't easy (nothing on that level is easy),
but Kid's matching is difficult. OTOH, it is true that a certain class
of errors (well formedness) is eliminated. But constantly validating
during development is not unreasonable (Paste even has a middleware for
this, of course ;).
OTOH, for programmers a markup based language does get you in the mind
of thinking of the structure of the page, not just the text. That's a
helpful mindset for working with Javascript. I wonder if it means
anything that Rails people primarily use innerHTML, and their templating
language is text based?
Anyway, while there's arguments back and forth, in my concrete
experience markup languages are harder.
Cheetah (like Django and ZPT) also has loose expressions which conflate
attributes, dictionaries, and methods; this is also useful for
non-programmers. Cheetah goes further than others by making those
expressions reasonably powerful as well (ZPT has no 'and' operator
without going into straight Python syntax, bah). This can add
complexity as well, so it's not a complete win.
OTOH, I've seen particular interest in quite a few programmers in TG
specifically because of Kid, or at least towards a markup-based
templating language. So it's not a bad choice, but it's catering to
programmers from what I have seen.
Ultimately, both Kid and Cheetah are good languages, this isn't
necessarily about N different templating languages. If another language
comes along with some good feature, one or the other of these two
languages can adopt that feature given some effort. But they both
represent two very different camps, and people have a certain emotional
reaction for or against them.
I like the idea behind Kid (xsl/python mix) but not at such a
performance cost, i'd rather have controllers serializing return
dict(...) in XML and using XSL.
Performance issues can be dealt with (and David Stanek has looked at
this some). XSL is only performant because of work put in on the
individual implementations to make it so. Likewise, Kid is a good
language to work with and there are many ways to address performance
issues in Python.
Cheetah feels like an improvement for a lot of people, i am sure it
would bring some new ppl to TG . It s rock solid/stable, has some
really nice features Kid lacks (powerefull caching, oo, no hassle with
well-formedness/entities, document output format).
"no hassle with well-formedness"? Ick. Especially as the migration
gradually occurs to XHTML, having well-formed documents and a system
that supports that will be a big bonus. I'm not sure what you mean by
"document output format"?
I personally think HTML is a perfectly good markup language, and XHTML
doesn't offer any compelling advantages for humans. But then ZPT
handles HTML just fine so I don't deal with this. It could potentially
be useful to extract whatever code does this from ZPT (at the
ElementTree level, I suppose -- it would be quite nice if ElementTree
had better HTML parsing support). Extracting from ZPT shouldn't be that
hard -- ZPT's code is not that scary! (It was even originally written
by Guido, so a nice lineage)
I'm also not certain that it's the template tool's job to do caching.
There are many places were one can conceivably do caching.
Granular output caching is probably best done in the template. OTOH,
Kid already has some structures which would probably facilitate this
reasonably.
Not to mention all the cheetah+framework "X" web apps which could be
converted to TG faster.
This is actually a real use case that I can get behind. In "What
TurboGears Is Not" [1], I state that having two ways of doing
something is fine as long as people know very clearly when to use one
or the other.
Incidentally Cheetah support would also solve the how-to-generate-text
issue. I think there's some other possible solutions for things like
email, but there's still cases when it's a useful function. Cheetah,
for instance, is a much better fit for generating Python source.
There's also been recent additions to it that may (I'm a little unclear)
make it appropriate for untrusted templates as well.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
