[XML-SIG] New to Python OO

[Fred L. Drake]

Michael Sanborn writes:
 > Suppose I wanted to create a customized method to write out a DOM tree,
 > say as plain text, like a totxt() paralleling toxml(). And say my
 > program
 > imports xml.dom.core and xml.dom.builder. I would have thought that the
 > way to approach this would be to define a local Node class derived from
 > core.py that added an empty totxt() method, and then to define local
 > subclasses of Node (such as Text) with specific totxt() methods. My
 > reasoning was that the Builder class would then build the tree with my
 > enhanced Nodes. But that doesn't seem to be happening. Instead, Builder
 > seems to be constructing the tree with regular core Nodes that don't

 > recognize my totxt() method. Can anyone give me advice on how to achieve
 > this?

  There are two questions that need to be addressed here:  1) How
should all this work, and 2) how to make it work now.
  Let's start with the second question, since it's easier.  This is an 
approach I've used to write out an ESIS stream, so I can claim it
works.  Write the transform you want as a function (or maybe an
object, if that's more conventient for state management), and pass the 
document to it.  It just needs to walk the tree and handle each node
type appropriately.  From your brief description, I'd say this
wouldn't be too hard.  (You may find the stuff in the formatter module
from the standard library handy as well.)
  What *should* be done is different.  ;-)  First, the DOM should
support the visitor pattern.  Not difficult to implement, but it's not 
in the DOM spec (yet).  This would allow transforms to be written more 
cleanly.
  The ability to subclass the node types and have the subclasses be
used would be really nice.  The builder (and anything else) should
only use the methods on the document object to create new nodes.  You
should then be able to subclass the Document class to make the factory 
methods do the right thing.  (Some details may need to change on the
builder, but that's trivial.)  The biggest issue with this is the
performance hit.  That may be more than is acceptable.
  Use of the visitor pattern would certainly be more useful and easier 
in most cases.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives
1895 Preston White Dr.	    Reston, VA  20191