Martijn Faassen wrote:
I don't think *recursive* documents are the norm? It may be that XSLT transformations can be far more complex, but since Stephan is doing 'real-world web publishing' with XML now, I don't think it's fair to say recursive documents are that incredibly common.
Well it may not be fair but it is true. :) Even HTML and DTML are recursive (lists within lists, tables within tables).
We have an DTML method called 'renderDocument' which renders the node title (for instance with a H1 tag), and then for all the section nodes, calls (with dtml-var) 'renderSection'. In renderSection, the title may be rendered with H2, for instance. Then it can go through all the contents, and see if it's encountering a P or a LIST node (for instance in a renderContents DTML method). This in turn calls the renderP and renderList DTML methods.
Right, this is how I would do it in ordinary Python. It's quite reasonable for small projects but you have a very strict binding between your document type's schema and your code. If you add a thing called "unorderedlist" which can appear anywhere a paragraph can appear you may need to change a dozen contexts (abstract, section, list item, etc.). So eventually you get tired of hard-coding what to do with each child node. You start to think: "Python's pretty flexible. There must be a way to emulate polymorphism." So you set up an array like this: def renderSection( sectionNode ): .... handlers["SECTION"] = renderSection And then in your loop you do something like: for subel in subelements: handlers[subelement.tagName](subel) That works great for a while but then you realize that the handling of (e.g.) a title is radically different depending on its context. So it doesn't make sense to always call handlers["TITLE"]. So you allow handlers to be tuples including context and maybe attributes: handlers[("SECTION","TITLE",{"attr":"bar"})] There. You've essentially reinvented XSL. It's no more complicated than that. That's why I say that this is where DTML will end up if it seriously persues the question of how to render XML.
If you want to see an example of this I can send you a .zexp file (or anyone else who asks :).
Please do!
Having said all this, I'm sure XSLT may be suited better to this kind of task, as it's specifically designed to do such. But DTML isn't bad at all, and, if you know Zope, it's not hard to whip something up (or change how the rendering works).
I agree. I just objected to the implication that Digital Creations had made something both simpler and more powerful for XML rendering than XSLT. It is probably simpler for simple problems and more powerful for really hard problems but in the vast middle ground it is not as optimized. Paul Prescod