Overview | Package | Class | Tree | Deprecated | Index | Help
| Xerces 1.2.1
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.apache.xerces.dom
Class DeepNodeListImpl

    java.lang.Object
      |
      +--org.apache.xerces.dom.DeepNodeListImpl

All Implemented Interfaces:
  NodeList

Direct Known Subclasses:
  NameNodeListImpl

public class DeepNodeListImpl
extends java.lang.Object
implements NodeList

This class implements the DOM's NodeList behavior for Element.getElementsByTagName()

The DOM describes NodeList as follows:

1) It may represent EITHER nodes scattered through a subtree (when returned by Element.getElementsByTagName), or just the immediate children (when returned by Node.getChildNodes). The latter is easy, but the former (which this class addresses) is more challenging.

2) Its behavior is "live" -- that is, it always reflects the current state of the document tree. To put it another way, the NodeLists obtained before and after a series of insertions and deletions are effectively identical (as far as the user is concerned, the former has been dynamically updated as the changes have been made).

3) Its API accesses individual nodes via an integer index, with the listed nodes numbered sequentially in the order that they were found during a preorder depth-first left-to-right search of the tree. (Of course in the case of getChildNodes, depth is not involved.) As nodes are inserted or deleted in the tree, and hence the NodeList, the numbering of nodes that follow them in the NodeList will change.

It is rather painful to support the latter two in the getElementsByTagName case. The current solution is for Nodes to maintain a change count (eventually that may be a Digest instead), which the NodeList tracks and uses to invalidate itself.

Unfortunately, this does _not_ respond efficiently in the case that the dynamic behavior was supposed to address: scanning a tree while it is being extended. That requires knowing which subtrees have changed, which can become an arbitrarily complex problem.

We save some work by filling the vector only as we access the item()s... but I suspect the same users who demanded index-based access will also start by doing a getLength() to control their loop, blowing this optimization out of the water.

NOTE: Level 2 of the DOM will probably _not_ use NodeList for its extended search mechanisms, partly for the reasons just discussed.

Since:
  PR-DOM-Level-1-19980818.
Version:

Field Summary
`protected int` | `changes`
`protected boolean` | `enableNS`
`protected java.util.Vector` | `nodes`
`protected java.lang.String` | `nsName`
`protected NodeImpl` | `rootNode`
`protected java.lang.String` | `tagName`

Constructor Summary
`DeepNodeListImpl(NodeImpl rootNode, java.lang.String tagName)` Constructor.
`DeepNodeListImpl(NodeImpl rootNode, java.lang.String nsName, java.lang.String tagName)` Constructor for Namespace support.

Method Summary
`int` | `getLength()` Returns the length of the node list.
`Node` | `item(int index)` Returns the node at the specified index.
`protected Node` | `nextMatchingElementAfter(Node current)` Iterative tree-walker.

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

Field Detail

### rootNode

    protected NodeImpl rootNode

### tagName

    protected java.lang.String tagName

### changes

    protected int changes

### nodes

    protected java.util.Vector nodes

### nsName

    protected java.lang.String nsName

### enableNS

    protected boolean enableNS

Constructor Detail

### DeepNodeListImpl

    public DeepNodeListImpl(NodeImpl rootNode,
                            java.lang.String tagName)

  Constructor.

### DeepNodeListImpl

    public DeepNodeListImpl(NodeImpl rootNode,
                            java.lang.String nsName,
                            java.lang.String tagName)

  Constructor for Namespace support.

Method Detail

### getLength

    public int getLength()

  Returns the length of the node list.
  Specified by:
    `getLength` in interface `NodeList`

### item

    public Node item(int index)

  Returns the node at the specified index.
  Specified by:
    `item` in interface `NodeList`
  Following copied from interface: `org.w3c.dom.NodeList`
  Parameters:
    `indexIndex` - into the collection.
  Returns:
    The node at the `index`th position in the `NodeList`, or `null` if that is not a valid index.

### nextMatchingElementAfter

    protected Node nextMatchingElementAfter(Node current)

  Iterative tree-walker. When you have a Parent link, there's often no need to resort to recursion. NOTE THAT only Element nodes are matched since we're specifically supporting getElementsByTagName().

Overview | Package | Class | Tree | Deprecated | Index | Help
| Xerces 1.2.1
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD