## org.apache.xml.dtm
Interface DTMFilter

public interface DTMFilter

Simple filter for doing node tests. Note the semantics of this are somewhat different that the DOM's NodeFilter.

Field Summary
`static int` `SHOW_ALL` Show all `Nodes`.
`static int` `SHOW_ATTRIBUTE` Show `Attr` nodes.
`static int` `SHOW_BYFUNCTION` Special bit for filters implementing match patterns starting with a function.
`static int` `SHOW_CDATA_SECTION` Show `CDATASection` nodes.
`static int` `SHOW_COMMENT` Show `Comment` nodes.
`static int` `SHOW_DOCUMENT` Show `Document` nodes.
`static int` `SHOW_DOCUMENT_FRAGMENT` Show `DocumentFragment` nodes.
`static int` `SHOW_DOCUMENT_TYPE` Show `DocumentType` nodes.
`static int` `SHOW_ELEMENT` Show `Element` nodes.
`static int` `SHOW_ENTITY` Show `Entity` nodes.
`static int` `SHOW_ENTITY_REFERENCE` Show `EntityReference` nodes.
`static int` `SHOW_NAMESPACE` This bit instructs the iterator to show namespace nodes, which are modeled by DTM but not by the DOM.
`static int` `SHOW_NOTATION` Show `Notation` nodes.
`static int` `SHOW_PROCESSING_INSTRUCTION` Show `ProcessingInstruction` nodes.
`static int` `SHOW_TEXT` Show `Text` nodes.

Method Summary
`short` `acceptNode(int nodeHandle, int whatToShow)` Test whether a specified node is visible in the logical view of a `DTMIterator`.
`short` `acceptNode(int nodeHandle, int whatToShow, int expandedName)` Test whether a specified node is visible in the logical view of a `DTMIterator`.

Field Detail

### SHOW_ALL

    public static final int SHOW_ALL

  Show all `Nodes`.

### SHOW_ELEMENT

    public static final int SHOW_ELEMENT

  Show `Element` nodes.

### SHOW_ATTRIBUTE

    public static final int SHOW_ATTRIBUTE

  Show `Attr` nodes. This is meaningful only when creating an iterator or tree-walker with an attribute node as its `root`; in this case, it means that the attribute node will appear in the first position of the iteration or traversal. Since attributes are never children of other nodes, they do not appear when traversing over the main document tree.

### SHOW_TEXT

    public static final int SHOW_TEXT

  Show `Text` nodes.

### SHOW_CDATA_SECTION

    public static final int SHOW_CDATA_SECTION

  Show `CDATASection` nodes.

### SHOW_ENTITY_REFERENCE

    public static final int SHOW_ENTITY_REFERENCE

  Show `EntityReference` nodes. Note that if Entity References have been fully expanded while the tree was being constructed, these nodes will not appear and this mask has no effect.

### SHOW_ENTITY

    public static final int SHOW_ENTITY

  Show `Entity` nodes. This is meaningful only when creating an iterator or tree-walker with an`Entity` node as its `root`; in this case, it means that the `Entity` node will appear in the first position of the traversal. Since entities are not part of the document tree, they do not appear when traversing over the main document tree.

### SHOW_PROCESSING_INSTRUCTION

    public static final int SHOW_PROCESSING_INSTRUCTION

  Show `ProcessingInstruction` nodes.

### SHOW_COMMENT

    public static final int SHOW_COMMENT

  Show `Comment` nodes.

### SHOW_DOCUMENT

    public static final int SHOW_DOCUMENT

  Show `Document` nodes. (Of course, as with Attributes and such, this is meaningful only when the iteration root is the Document itself, since Document has no parent.)

### SHOW_DOCUMENT_TYPE

    public static final int SHOW_DOCUMENT_TYPE

  Show `DocumentType` nodes.

### SHOW_DOCUMENT_FRAGMENT

    public static final int SHOW_DOCUMENT_FRAGMENT

  Show `DocumentFragment` nodes. (Of course, as with Attributes and such, this is meaningful only when the iteration root is the Document itself, since DocumentFragment has no parent.)

### SHOW_NOTATION

    public static final int SHOW_NOTATION

  Show `Notation` nodes. This is meaningful only when creating an iterator or tree-walker with a `Notation` node as its `root`; in this case, it means that the `Notation` node will appear in the first position of the traversal. Since notations are not part of the document tree, they do not appear when traversing over the main document tree.

### SHOW_NAMESPACE

    public static final int SHOW_NAMESPACE

  This bit instructs the iterator to show namespace nodes, which are modeled by DTM but not by the DOM. Make sure this does not conflict with `NodeFilter`.

  %REVIEW% Might be safer to start from higher bits and work down, to leave room for the DOM to expand its set of constants... Or, possibly, to create a DTM-specific field for these additional bits.

### SHOW_BYFUNCTION

    public static final int SHOW_BYFUNCTION

  Special bit for filters implementing match patterns starting with a function. Make sure this does not conflict with `NodeFilter`.

  %REVIEW% Might be safer to start from higher bits and work down, to leave room for the DOM to expand its set of constants... Or, possibly, to create a DTM-specific field for these additional bits.

Method Detail

### acceptNode

    public short acceptNode(int nodeHandle,
                            int whatToShow)

  Test whether a specified node is visible in the logical view of a `DTMIterator`. Normally, this function will be called by the implementation of `DTMIterator`; it is not normally called directly from user code.
  Parameters:
    `nodeHandle` - int Handle of the node.
    `whatToShow` - one of SHOW_XXX values.
  Returns:
    one of FILTER_ACCEPT, FILTER_REJECT, or FILTER_SKIP.

### acceptNode

    public short acceptNode(int nodeHandle,
                            int whatToShow,
                            int expandedName)

  Test whether a specified node is visible in the logical view of a `DTMIterator`. Normally, this function will be called by the implementation of `DTMIterator`; it is not normally called directly from user code.

  TODO: Should this be setNameMatch(expandedName) followed by accept()? Or will we really be testing a different name at every invocation?

  %REVIEW% Under what circumstances will this be used? The cases I've considered are just as easy and just about as efficient if the name test is performed in the DTMIterator... -- Joe

  %REVIEW% Should that 0xFFFF have a mnemonic assigned to it? Also: This representation is assuming the expanded name is indeed split into high/low 16-bit halfwords. If we ever change the balance between namespace and localname bits (eg because we decide there are many more localnames than namespaces, which is fairly likely), this is going to break. It might be safer to encapsulate the details with a makeExpandedName method and make that responsible for setting up the wildcard version as well.

  Parameters:
    `nodeHandle` - int Handle of the node.
    `whatToShow` - one of SHOW_XXX values.
    `expandedName` - a value defining the exanded name as defined in the DTM interface. Wild cards will be defined by 0xFFFF in the namespace and/or localname portion of the expandedName.
  Returns:
    one of FILTER_ACCEPT, FILTER_REJECT, or FILTER_SKIP.

Copyright © 2006 Apache XML Project. All Rights Reserved.