> Why DOM_Node::cloneNode() does not clone the pointer assigned to a NOM_Node via > DOM_Node::setUserData()? Not A Bug. This should be in a FAQ document somewhere: There are several possible options for how cloneNode should handle userData: 1) Copy the pointer. May be a Very Bad Idea if you really wanted the data associated with a particular node object. 2) Clone the object being pointed at. Maybe a Very Bad Idea if that object, in turn, wasn't designed to be cloned at this time. 3) A complex call-back API has been proposed which would allow the userData object to tell the DOM which of these three options should be taken, but that would require that only objects implementing that API be registered as userData. That doesn't seem to be a good option. 4) Do nothing. This is by far the lowest-overhead and safest choice. And since cloneNode is a DOM operation, and userData is _not_ defined by the standard DOM API, one can make a very strong case for this being the "most correct" option. We chose (4), very deliberately. If you want one of the others, you can implement it by creating your own wrapper operation for cloneNode() and calling that. NOTE that userData should be considered a nonportable, experimental feature of the Xerces DOM. It may evaporate entirely in favor of a scheme based on the DOM Level 3 "node key" mechanism, when that becomes officially available. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
