0xDECAFBAD

It's all spinning wheels and self-doubt until the first pot of coffee.

Cross-breeding XSLT and ZPT

I've recently been doing some side work involving Zope and, along with the rest of the suite of technologies it offers, I've been happy to be working with Zope Page Templates again. I dabbled with them a bit when they first came out, and a Zope-free implementation named SimpleTAL was one of the core components of the iteration of my news aggregator which came before FeedReactor.

Out of all the templating and content generation approaches I've used, Zope Page Templates are my favorite yet. Pretty expressive, yet unobtrusive; nicely powerful, yet not quite something with which you'd want to write an entire application (and that's a feature, not a bug).

I've yet to be in a work-a-day team that uses ZPT-- but I can see where a lot of production, delegation, and integration issues would have gone much smoother had I used ZPT instead of Template Toolkit for the web app framework I created at a previous company. (Though I do have to say TT2 is very nicely done!) And where I am now, I spend most of my days trying to pummel ASP 3.0 pages into some semblance of logic/presentation separation-- I would certainly dive at the chance to dump VBScript and <% cruft %> for a bit of Python and ZPT. (But, you know, it's a living.)

A close second favorite is XSLT. I've really been hot on it lately, having worked it into the core of FeedReactor in place of SimpleTAL. And in other hacks, I've really come to appreciate it's role as a filter segment in pipelines between REST web services and URL-as-command-line invocations.

Granted, both ZPT and XSLT very different technologies, but they are often used in similar contexts. More than once, I've wished that XSLT was as simple as ZPT (i.e. less verbose and intrusive, more document centered), and I've wished that ZPT had some of the features of XSLT (i.e. ability to be used as a transforming filter).

Reading Ryan Tomayko's description of Kid got me thinking, and googling. One thing I turned up from a mailing list archive asked about an “XSL implementation of TAL?” It struck me as a tad nutty at first, but then I started having inklings that just maybe it could be done. (Whether it should be done, well...) But the kernel of the idea grabbed me: Instead of using TALES path expressions to look up values in Pythonic space, why not use XPath expressions to look up values from a supplied XML document?

This strikes me as such an obvious idea that someone has to already have done it and possibly rejected it for good reason. On the other hand, maybe this is the sort of thing Ryan's thinking about-- I wonder how hard it would be to hack this into Kid? It would give only a subset of XSLT's capabilities in trade for simplicity, and would only offer the “pull” approach, but it would give XML-pipelining to a ZPT-ish technology.

I think this is something I want to look into a bit further at some point.

shortname=crossbreedingxsltzpt

Archived Comments

  • Ian Bicking
    I've been meaning to write about this on my blog, as I've done something similar. Instead of using XSLT, I've used ZPT for the transformations. It was an application where the user created a document in a WYSIWYG editor, then we wanted to pull information out of the content -- like a table of contents, or a title. To do this I parsed the content into a DOM, then put some objects in the ZPT namespace that manipulated it. For instance, the ToC object took a tag name (through getitem) and returned a list of the content and id of those tags (it created ids if necessary, modifying the content). Then you could easily create a ToC by looking through and creating anchor tags from, say, all the tags in the document. It should be easy to expand with other transformations (all coded in Python, of course). The actual code was only like 20 lines of Python, maybe less, and easy to understand from both sides (ZPT and Python).
  • Petri Savolainen
    See http://zope.org/Members/DaddyGravity/PT_XPath It would be great to have that in SimpleTAL, too.
  • Ian Bicking
    Another thing you might want to look at: in the last few days there's been discussion on the ZPT mailing list about an extension to stylesheets (TERSE) for ZPT that introduces transformations.
  • Bertrand Delacretaz
    FYI, people from the Apache Cocoon and BXE projects are working on similar stuff, in the opposite direction: we're taking TAL-like templates and converting them to XSLT, adding simple "match" templates for declarative rules. It's only prototypes and experiments for now, but the results look promising. More info at http://wiki.apache.org/cocoon/HtmlToXsltExperiments and http://blog.bitflux.ch/archive/further-improvements-on-xsl-tal.html
  • Manuzhai
    I like XSLT a lot, myself, and I have advocated it in the past on my weblog, but it just doesn't seem to be very wide-spread. Which is a pity, I think the world would be much easier if more people used this *standard* way of templating. One of the bigger problems with it seems to be the verbosity, so I've been thinking of a more compact syntax, kind of like RELAX NG has the .rnc compact stuff. I don't know if it's very feasible, but it seems like that would be not very hard; just have some compact syntax which maps onto a real XSLT-sheet (it could be "compiled" and cached, if need be).
  • Colin Stewart
    Integrating an XPATH implementation into SimpleTAL shouldn't be too hard as the TALES and TAL implementations share a fairly simple interface. There are 6 methods you'd have to provide to the simpleTAL module and that's about it. I don't know if XPATH is the right approach though - how would things like tal:define work if the paths were pure XPATH instead of TALES? Being able to mix XPATH and TALES would work better I think. A more promising approach would be to integrate ElementTree so that the 'find*' methods were usable from within TALES. Making it so that '/mydoc/root/find/.//searchElement' works would be fairly easy, but getting '/mydoc/root/find/.//searchElement/attrib/firstAtt' to work would require more co-operation between ElemenTree and SimpleTAL. I'll have a think about this though as it sounds like a promising approach.
  • Paul Everitt
    Chapter 11 of Jeni Tennison's "XSLT and XPath On The Edge" book has a section called "Using Page Templates". It includes an example of using substitution points. Like some of the others in this thread, playing with doing merges using DOM IDs and other patterns. This lets you write "themes" that are simpler than even ZPT, as they contain no non-XHTML namespace elements. Thanks for the article, which also seems to have brought out some interesting comments and URLs!
  • Bill Seitz
    Don't forget you can run Python within IIS/ASP! http://webseitz.fluxent.com/articles/PythonViaIis
  • Colin Stewart
    I've put together an experimental build of SimpleTAL that integrates ElementTree to provide some of the XPATH syntax. It's just an experiment, but see what you think. (More detail here: http://www.owlfish.com/weblog/2004/12/15122004.html#20:59:59)