Re: Re: Problem with implementation of getChildNodes on HTMLFormElement?

At 01:00 PM 9/13/2003 -0500, you wrote:
>Ok, I narrowed it down.  Try adding "-dom xerces" to the XMLC 
>compilation.  You will find that it works fine with or without calling 
>getFirstChild().  I figured this out after printing out all the child node 
>class names and noticed that they were LazyDOM classes (which I knew 
>anyway, but this just reminded me to notice that fact).
>
>So, it probably isn't a problem with Xerces, but with LazyDOM.

Ok, I think I figured out the problem.  I hadn't realized it before, but 
the lazydom HTMLFormElementImpl.java explicitly overrides 
getChildNodes().  Here is what it looks like including the Javadoc comments...

<quote>
     /*
      * Explicit implementation of getChildNodes() to avoid problems with
      * overriding the getLength() method hidden in the super class.
      */
     public NodeList getChildNodes() {
         return getChildNodesUnoptimized();
     }
</quote>

I checked the Xerces HTMLFormElementImpl.java and this is really just taken 
directly from there.  Basically, the normal lazydom node expansion that 
happens before the elements are returned in LazyElementNoNS.java doesn't 
happen for form elements.  However, the getFirstChild() isn't overridden 
and carries out the normal expansion.  Once the nodes are expanded, 
getChildNodes() will be dealing with a pre-expanded set of nodes and return 
them as expected.

The fix involves two things...

1.  Change the HTMLFormElementImpl#getChildNodes() method to look like this...

     public NodeList getChildNodes() {
         if (!areChildrenExpanded()) {
             expandChildren();
         }
         return getChildNodesUnoptimized();
     }

2.  Change HTMLElementNoNS#expandChildren() method "protected" rather than 
"private" so that HTMLFormElementImpl actually as access to it.

I tested this fix on Petr's testcase and it works even when using "-dom 
lazydom"!


I think this change is reasonable and I'll check it in soon unless I hear 
otherwise from other XMLC developers.  David, Richard, Mark, can you let me 
know if this change is ok?  If I don't hear from you, I'll assume it is and 
check it in, so if you don't like it make sure you speak up.


Jake