Just looked at Python Templating Languages. I'm familiar with the main three (DTML, ZPT, and Cheetah). I assume the fourth (STL) is written by the author. I don't really agree with the way the paper lays out the issues, though it appears to be a draft. Here's how I'd score it (leaving out STL, which I don't know about): table.comparison td { border: 1px #666666 solid; }
| Cheetah | DTML | ZPT | |
|---|---|---|---|
| Documentation | 3 | 2 | 2 |
| How can the Cheetah docs not get a 3? ZPT is generally better documented than DTML, as it has a more easily documented scope, but it's a close call. They both have a considerable quantity of documentation, but both suffer from a lack of well-structured documentation, and have poorly documented corners. The internals (analogous to what Cheetah's Developers' Guide covers) are not documented much at all -- probably because they are meant only for a single environment (Zope). ZPT and DTML are documented in many books, but the books tend to be spotty. | |||
| Community | 2 | 2 | 3 |
| Easiness to fix errors | 1 | 0 | 3 |
| Debugging Cheetah means reading through the generated Python source, which isn't so good. There are also some misleading error messages that can occur. So that's not so hot. Still better than the travesty that is DTML. ZPT does really well, though -- excellent tracebacks, helpful parse errors. | |||
| Easiness to update | I don't really get this one | ||
| Easiness to refactor | This one is subtle, and depends on a lot more than just the templating mechanism. It's too hard to judge for me. | ||
| Learning curve | 2 | 2 | 1 |
| I think the imperative style of Cheetah and DTML is easier to understand, at least for someone that works with HTML textually (i.e., not through a WYSIWYG editor or other structured editor). Cheetah is also easier for a Python programmer -- probably easier than DTML in this case -- because it parallels Python. ZPT's promise of allowing people to edit code with a WYSIWYG editor has not panned out, and I don't think it is a practical goal at this time. | |||
| Allow embedded code | 2 | 0 | 2 |
| I disagree with the author on fundamentals here -- I think embedded code is good, though potentially dangerous. I think ZPT makes a pretty good compromise here, though depending on how you structure your code, Cheetah could be better. I can't really decide. However, DTML's embedded code is a travesty. STL's lack of simple operators (like not:) is nothing to be proud of -- ZPT's tags are all there for a reason, and I've used all of them, and it's not because I'm breaking the MVC barrier. As I've gotten more used to ZPT, I rely on Python Scripts more and ZPT less for calculations, but I still use Python often in ZPT -- how else can you make a <select> element? | |||
| Is the template valid HTML | 1 | 0 | 3 |
| Cheetah actually can be valid HTML, depending on your template, while DTML cannot. And DTML's interaction with HTML is obnoxious, e.g.: <a href="<dtml-var a_url url_quote>">. That's just horrid. There's also a downside that the author doesn't mention, that Cheetah and DTML can be used to create non-HTML (email, config files, etc), while ZPT cannot. | |||
| Elegance | 2 | 0 | 2 |
| This is obviously a subjective measure. I can only say that DTML sucks from many perspectives, while Cheetah and ZPT suck only from a few perspectives. ZPT is tiresome to write. Cheetah allows invalid markup. DTML is tiresome to write and allows invalid markup. And so on. | |||
| Render speed | 3 | 2 | 1 |
| I'm guessing here, but these are from my general experience. Cheetah compiles to Python, so it's very fast (well, at least comparable to Python). DTML is interpreted, but ZPT is noticeably slower. | |||
There are perhaps some other important templating languages out there. DTML isn't an important language. No one should use DTML, unless you are developing a legacy Zope application. Or, sadly, when generating email or SQL in Zope, but that's just an unfortunate corner case. No one outside of Zope can reasonably use DTML (and there's no reason to). ZPT is the way to go (and it can be used outside of Zope: zpt.sf.net, SimpleTAL).
Some other, more interesting templating languages might be Spyce, which embeds Python in the markup (as easy to learn as Python, but obviously with issues), or htmltmpl, which is interesting in that it supports Python and PHP, and is a better example than DTML of a tag-based templating language. There's also Nevow, for another ZPT-style templating system. Finally, there's a list of templating languages on the Python Wiki, though it's not complete.
I edit ZPT in GoLive often. It took only some minor coaxing and you do have to keep an eye on what's going on when working in visual mode, but it *can* work.
Beyond that, ZPT has really really gelled in my brain, with or without a visual or structured editor. It is a weird learning curve as it's a style that's somewhere between imperative structures like Cheetah and whatever XSLT is.
Thanks to ZPT, I've stopped treating HTML textually, almost completely. Each select widget, hyperlink, becomes a living breathing object instead of merely a placeholder for a value to be inserted. I really like that it allows me to do this without my having to wrap my head around more painful DOM concepts.
ZPT *can* be used to make non-HTML files, but it's painful and is stepping outside its design goals. But it can be done (I see people do it on occasion, and I'm always shocked).
I especially agree with you on ZPT's compromise on embedded code. The TALES engine (which potentially allows other expression languages to be installed) is a really nice feature, and I like that you can use Python to do complex conditionals, extra formatting, and so on, without yet another micro-language having to be invented. The TALES engine also allows the actual TAL language definition to remain quite small and simple.
With very few exceptions, all of my sites have been much easier to maintain since moving to ZPT, and it's been a lot easier to work with our design team. The developers still add in almost all of the TAL/METAL statements when they hand us their designs, but the big savings tend to come when we have to do major design changes.
em.py is also a nice and fast templating system.# Frank
When I was looking for a new templating system for Roundup, I settled on ZPT pretty quickly. I have the occasional Roundup user who complains about the complexity (while, at the same time, being able to get the job done), but most users are happy with it. The i18n stuff in ZPT can be fiddly though.
Personally, the ZPT design (TAL, TALES, METAL) just work for me.
One issue that's come up in Roundup though is templating of plain text. As Jeffrey points out, non (HT+X)ML is something that ZPT is definitely *not* targetted at (and is why DTML persists in Zope, as you point out). Still looking for something elegant there -- I wonder if anyone's implemented a perl-format-alike in Python...
Note that SimpleTAL isn't a complete implementation, and isn't as mature. It's definitely usable, and is getting more mature though.
Ian: "There's also Nevow, for another ZPT-style templating system."
Nitpick: I think this mischaracterises Nevow somewhat, as there's a significant difference in how Nevow (specifically Nevow.renderer) and ZPT work. While ZPT keeps its basic flow control structures into HTML templates, Nevow does all flow control from Python via a programmatic interface. Templating systems like Nevow, PyMeld and my HTMLTemplate are conceptually closer to DOM and desktop-GUI systems than to macro-descended/influenced embedded templating language-based systems like PHP, Cheetah, TAL, etc.
(Historical note: It was actually ZPT that gave me the original idea for HTMLTemplate. I just took the custom tag attributes and callback-into-Python concepts, boiled them down as far as they could go, and fused them to what I already knew about DOM and application scripting.)
BTW, I'm not sure why the paper's author classes STL with PyMeld, as STL falls into the embedded language camp. He also seems to suggest that PyMeld is templating language-based, which it's not. Anyway, I thought the paper read more like a puff-piece for STL than a objective assessment of the full templating engine arena. Not that I object to puff per-se, but I do think it should have provided a full disclosure so readers will know where the author is coming from. A pity, as with all the different templating systems currently floating about it would be nice to have a really good, objective comparison to help both developers and users judge their pros and cons better.
I have bloged this at
http://davew.typepad.com/42/2004/06/ian_bicking_pyt.html
Tried trackback and it did not work.
I wanted to find out more about STL, but Olivier Guilloux's article didn't appear to provide a reference. However he mentions that STL is used by the itools community. It turns out that STL is part of J David Ibáñez's itools package.# Hamish Lawson
I'm always amused to see that "you can't generate plain text with a ZPT" given that I first read this immediately after editing an ZPT that did exactly that. It's certainly hammering a square peg into a round hole, though.
I really like ZPTs. I'm not sure why, I guess it's because they were designed by people who actually knew what a templating system was FOR.
One of my needs is to place style information into HTML. My
application uses wxPython which in turn uses wxWidgets. The
wxWidgets HTML viewer does not support style sheets, or the
class attribute. This is actually the hard part. The templating
itself is actually easy.
This is what I do at the moment:
- First pass over the template using xyaptu from the Python
cookbook. This is an example template:
http://cvs.sf.net/viewcvs.py/bitpim/bitpim/resources/pblayout.xy?view=markup
In particular note that I do use class attributes which
are ignored by the wxWidgets HTML viewer.
- Do a second pass using HTMLParser.HTMLParser which generates a
tree of the document structure (it also requires the HTML to
be perfect with *all* tags having matching closes. I then have
a file that defines styles.
http://cvs.sf.net/viewcvs.py/bitpim/bitpim/resources/styles.xy?view=markup
That says where to inject style information. The dict says what
attributes to add to the tag the class was found in (the '' case)
and then also lists how tags contained within should be modified.
Later down there are also tags that get added.
So I have a fairly big mess. I am having to simulate style-sheets,
produce 100% correct HTML and also have various value formatting
functions all over the place.
I actually like PHP's Smarty the best, mainly for the modifiers
and being able to do things like capture.
For repetitively updated information, specifically server-pushed real-time industrial process displays, I think that PyMeld is particularly appropriate (and elegant in its Pythonic simplicity). The same approach for (X)HTML extends automatically to SVG, whose future blending is represented by recent Firefox/Mozilla development. Additionally, any other templating scheme can still be used to publish "snapshots" of the displays as well.
I love PyMeld and think its a fantastic system, but in real life situations it is extremely slow in my experience. At some stage I will try and do some formal benchmarks but for a recent project (http://muti.co.za) I started off using PyMeld and then abandoned it. I found that in generating a table with multiple rows (around 30 or so) using the recipe described by the PyMeld author, it was two orders of magnitude slower than Pythons "%" native templates.
I then tried Cheetah, and although it is faster than PyMeld to my horror I found that it is 1 order of magnitude slower than straight "%" templates. This was Cheetah 1.0 (At the time I did this 2.0RC1 was out but I didnt try it). I at first thought this was because I wasnt using the compilation functionality but I found that compiling the templates produced very little difference with the same 30 line table.
I also tried the new Python 2.4 template engine in the string module, and this was disapointing in that it was marginally slower than % templates and also has no support for numeric formatting. I probably could have used Cheetah but I am very picky about performance and in the end I could not justify an order of magnitude performance hit so I am using straight % templates until I can find a higher performing template engine.
meld3 might be faster than PyMeld. For Cheetah, you lose a lot of performance with NameMapper -- if you don't use it (try taking out $'s) it might speed up significantly.
# Ian Bicking