Java Doc for ParentNode.java in  » XML » xerces-2_9_1 » org » apache » xerces » dom » Java Source Code / Java DocumentationJava Source Code and Java Documentation

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!
author:
   Arnaud Le Hors, IBM
author:
   Joe Kesselman, IBM
author:
   Andy Clark, IBM
version:
   $Id: ParentNode.java 447266 2006-09-18 05:57:49Z mrglavas $

• The inserted child is a text node and one of its adjacent siblings is also a text node.
• The inserted child is is itself unnormalized.

• The removed child had two adjacent siblings that were text nodes.

Example: Cloning a Text node will copy both the node and the text it contains.

Example: Cloning something that has children -- Element or Attr, for example -- will _not_ clone those children unless a "deep clone" has been requested. A shallow clone of an Attr node will yield an empty Attr of the same name.

NOTE: Clones will always be read/write, even if the node being cloned is read-only, to permit applications using only the DOM API to obtain editable copies of locked portions of the tree.

NodeLists are "live"; as children are added/removed the NodeList will immediately reflect those changes. Also, the NodeList refers to the actual nodes, so changes to those nodes made via the DOM tree will be reflected in the NodeList and vice versa.

In this implementation, Nodes implement the NodeList interface and provide their own getChildNodes() support. Other DOMs may solve this differently.

To use this method, the subclass should implement getChildNodes() and have it call this method. The resulting NodeList instance maybe shared and cached in a transient field, but the cached value must be cleared if the node is cloned.

See Also:   Note: this will not change the state of an EntityReference or its
See Also:   children, which are always read-only.