Skip to content.

plope

Personal tools
You are here: Home » Members » chrism's Home » Python DOM Manipulation Templating Systems
 
 

Python DOM Manipulation Templating Systems

A quick look at the current crop of Python-based "DOM manipulation" templating systems.

I was actually suprised at the current number of Python "DOM manipulation" templating systems. DOM manipulation templating systems differ from "embedded-language" templating systems inasmuch that there is exactly zero logic in the template file itself (no loops, no conditionals, etc). Instead, it's assumed that the template will be rendered by serialization of a mutation of a node tree. The "mutation" bit is done via plain old Python code.

HTMLTemplate is Hamish Sanderson's crack at an XML/HTML templating system that appears to be influenced by various Apple design patterns. Licensed under the LGPL.

texttemplate is another work by Hamish that uses the same pattern as HTMLTemplate but can accept non-XML/HTML input and generate non-HTML/XML outtput. Also licensed under the LGPL.

PyMeld is an HTML/XML DOM manipulation system by Richie Hindle that can be used within non-commercial code without special consideration (Sleepycat license).

meld3 is my own take on an XML/HTML DOM manipulation system, loosely based on the ideas of PyMeld. (ZPL).

meld4 is Peter Hunt's take on PyMeld. (BSD). Peter talks about why he thought it was a good idea to write this in his blog .

Hamish Sanderson has some cogent comments on DOM manipulation systems vs. embedded language systems in comments to one of Guido's blog posts .

Created by chrism
Last modified 2006-02-06 07:29 AM

Hamish on coupling FUD

Posted by slinkp at 2006-02-06 10:51 AM
Hamish ("has") explains very well here that the "tight coupling" argument against DOM approaches doesn't wash:

http://www.artima.com/forums/flat.jsp?forum=106&thread=146647&start=34&msRange=15

What people tend to overlook when they make the coupling argument is
the coupling they've already accepted between visual design and
the template code, and that this inevitably requires two people to
make changes: the graphic designer and the programmer.
DOM approaches should make it possible to break that coupling.

Also, as you've found in your meld3 experiments, you can further reduce the coupling between the template and the manipulation code by emphasizing IDs as *the* way to get at nodes (as opposed to something more flexible like ElementTree().which reduces the chance that template restructuring will require code changes. That's one thing that I think is an advantage
of the Meld family over some of the other DOM-like approaches - and that's also why I've been thinking that we maybe don't want to expose the entire Element API in meld3.

HTMLTemplate

Posted by slinkp at 2006-02-06 10:52 AM
I do like the look of HTMLTemplate, it's sensibly data-driven, which I think is definitely the way to go if you put any special markup in your template.
Think ZPT with only simplified path expressions, or ClearSilver without the gunky *SP-style syntax. This is what we've learned the hard way to do in ZPT anyway.

Slight correction re. HTMLTemplate

Posted by has at 2006-02-07 06:15 PM
HTMLTemplate supports HTML and XHTML, but not XML unfortunately. You can pass in XML if you want, but Python's HTMLParser module automatically lowercases tag and attribute names and will make a right muck of it if you're not careful. I'd like it to support XML eventually, but it probably means changing parsers so I haven't gotten around to it so far. Maybe when I get chased with a big stick. ;)

HTH

Does Kid count?

Posted by neaj at 2006-05-19 05:27 AM
Does Kid count, or does embedded Python blocks disqualify it?

http://kid.lesscode.org/