[Zope-dev] RE: ZDOM patches

Amos Latteier Amos@digicool.com
Mon, 18 Oct 1999 18:27:39 -0400


Anthony Pfrunder wrote:

> I'll submit them again but basically this is how to patch it:
> 	* For all creation DOM methods (clone, createXX ...) you need
> 	  to add some hidden magical methods to stop weird errors from 
> 	  occuring.  Here is how:
> 
> # This makes the aquisition path point to the current containing
> # document.  These attributes doesn't exist after a creation 
> call hence,
> # aquisition doesn't work properly.
> 
> def XMLpatch(self, p):
> 	p.aq_acquire = self.aq_acquire
> 	p.aq_base = self.aq_base
> 	return p
> 
> Then, for each creation call wrap it like such:
> 
> def createTextNode(self, data):
> 	return self.XMLpatch(Document.createTextNode(self, data)) 
> 
> here, Document is an XML document and data is the actual 
> content of the
> Text Node (I think).

Hmm. I'd like to know more about what sort of weird errors this patch
fixes. (Ideally I like to see a snippet of code which demonstrates the
problem.)

In general, hacking an object's 'aq_acquire' method and 'aq_base'
attribute is not a good idea. In general the right thing to do is to
wrap an object with an acquisition wrapper so that it has the correct
acquisition context.

That said, I've been talking with Martijn Faassen about some ways in
which the XML Document doesn't work well with the DOM API because of
acquisition.

The problem is that the DOM seems to assume that arguments to methods
are changed. For example,

  foo.removeChild(bar) # does not actually change bar's parent

is assumed to change bar, not just foo. This doesn't work with XML
Document since it uses acquisition to keep track of parent nodes. Since
bar is an acquisition wrapper (which is immutable) we cannot change its
parent. Note however, that most DOM methods like this return their
arguments so you can get the changed bar as the return value of this
method.

  bar=foo.removeChild(bar) # returns correctly wrapped bar

It's fairly easy to work around these problems, but still it would be
nice to have a more robust solution, since this sort of gotcha is
subtle, and likely to trip up folks. It may be that using acquisition is
not the right solution for XMLDocument Nodes to keep track of their
parents. I'm open to suggestions (and patches).

-Amos

--
Amos Latteier         mailto:amos@digicool.com
Digital Creations     http://www.digicool.com