[Zope] Re: XSL and DTML was: a funny thing happened today...

[Paul Prescod]

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