Re: question(bug) about setNodeValue

At 04:57 PM 9/18/2003 -0500, you wrote:
> > Accroding to api doc, setNodeVaule can accept null parameter:
> >
> > The value of this node, depending on its type; see the table above. When it
> > is defined to be null, setting it has no effect.
>
> Hmm......  So, does this mean that the initial value shouldn't have been 
> modified?  In the DOM, what is the initial value of a Text node?  Can it 
> be null or would that, by definition, mean that there wouldn't be a text 
> node in the first place?  It it couldn't be null as an initial value and 
> passing null to setNodeValue() is supposed to leave the initial value 
> alone rather than set it to null, then how could a Text node value of null 
> be passed to BaseDOMFormatter#writeText()?  We could certainly do the null 
> check in the writeText() method, but should we have to do that?  Would 
> that even be the correct thing to do?  Seems like the bug here might lay 
> somewhere in the Xerces1 DOM implemementation.  Thoughts anyone?

Ok, I gave my brain some food and all of a sudden things made more 
sense.  Go figure.  It says that when the table defines the node value to 
be "null", then the setting has no effect.  Of course, for a node of type 
"Text", the value is defined to be "content of the text node".  So, if one 
sets uses setNodeValue(null), the "content of the text node" will be 
"null".  As such, it looks as if BaseDOMFormatter#writeText() should be 
checking for null and just returning immediately if the value is null.

Note that Attr nodes which are set to null don't seem to run through this 
method and end up looking like boolean attributes (eg...  'onclick" rather 
than then expected and legal onclick="").  I'm not sure currently where 
those are serialized?  I tried the following ways of setting Attr nodes to 
null...

org.w3c.dom.Element node = xmlObj.getElementById("foobar");

node.setAttribute("onclick", null);
or...
node.getAttributeNode("onclick").setNodeValue(null);

In neither case did writeText() get called for serializing those Attr 
nodes, although other non-modified Attr nodes did pass through 
writeText().  Hmm....  This seems like bad behavior.  If anyone has an idea 
where this is serialized, it would be nice to know so we can fix it to make 
it consistent with Text node behavior.

Anyway, I'm checking in the null check change which will fix the null 
pointer exception.  The existing Text node value will be wiped out when 
setting the value to "null" rather than bombing out.

Jake