[Anthony's patches to XMLDocument creation functions snipped] Ah, I had seen these and discussed them with Amos, but I just wasn't sure if *you* had. :) Amos Latteier wrote:
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.)
I'm curious too. I could try them out sometime with my XMLWidgets/ZAML system, I suppose.
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.
[snip]
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.
As I mentioned to Amos, the problems can be triggered in more subtle ways too: For instance: # temporarily store reference to first child of node temp = node.getFirstChild() # remove all child nodes of node for child in node.getChildNodes(): node.removeChild(child) # now try to add temp again node.appendChild(temp) One can work around this one too, but I just wanted to point out it can be more difficult than just using the return value. I'd be nice if Anthony had some data on how his patches behave under these circumstances.
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).
Still thinking about this one. :) Regards, Martijn