Author(s)Arnaud Le Hors, IBM, Joe Kesselman, IBM, Andy Clark, IBM
ParentNode inherits from ChildNode and adds the capability of having child
nodes. Not every node in the DOM can have children, so only nodes that can
should inherit from this class and pay the price for it.
ParentNode, just like NodeImpl, also implements NodeList, so it can
return itself in response to the getChildNodes() query. This eliminiates
the need for a separate ChildNodeList object. Note that this is an
IMPLEMENTATION DETAIL; applications should _never_ assume that
this identity exists. On the other hand, subclasses may need to override
this, in case of conflicting names. This is the case for the classes
HTMLSelectElementImpl and HTMLFormElementImpl of the HTML DOM.
While we have a direct reference to the first child, the last child is
stored as the previous sibling of the first child. First child nodes are
marked as being so, and getNextSibling hides this fact.
Note: Not all parent nodes actually need to also be a child. At some
point we used to have ParentNode inheriting from NodeImpl and another class
called ChildAndParentNode that inherited from ChildNode. But due to the lack
of multiple inheritance a lot of code had to be duplicated which led to a
maintenance nightmare. At the same time only a few nodes (Document,
DocumentFragment, Entity, and Attribute) cannot be a child so the gain in
memory wasn't really worth it. The only type for which this would be the
case is Attribute, but we deal with there in another special way, so this is
not applicable.
This class doesn't directly support mutation events, however, it notifies
the document when mutations are performed so that the document class do so.
WARNING: Some of the code here is partially duplicated in
AttrImpl, be careful to keep these two classes in sync!
ParentNode, just like NodeImpl, also implements NodeList, so it can return itself in response to the getChildNodes() query. This eliminiates the need for a separate ChildNodeList object. Note that this is an IMPLEMENTATION DETAIL; applications should _never_ assume that this identity exists. On the other hand, subclasses may need to override this, in case of conflicting names. This is the case for the classes HTMLSelectElementImpl and HTMLFormElementImpl of the HTML DOM.
While we have a direct reference to the first child, the last child is stored as the previous sibling of the first child. First child nodes are marked as being so, and getNextSibling hides this fact.
Note: Not all parent nodes actually need to also be a child. At some point we used to have ParentNode inheriting from NodeImpl and another class called ChildAndParentNode that inherited from ChildNode. But due to the lack of multiple inheritance a lot of code had to be duplicated which led to a maintenance nightmare. At the same time only a few nodes (Document, DocumentFragment, Entity, and Attribute) cannot be a child so the gain in memory wasn't really worth it. The only type for which this would be the case is Attribute, but we deal with there in another special way, so this is not applicable.
This class doesn't directly support mutation events, however, it notifies the document when mutations are performed so that the document class do so.
WARNING: Some of the code here is partially duplicated in AttrImpl, be careful to keep these two classes in sync!