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

    Fields
    Modifier and Type
    Field
    Description
    static final int
    Show all Nodes.
    static final int
    Show Attr nodes.
    static final int
    Special bit for filters implementing match patterns starting with a function.
    static final int
    Show CDATASection nodes.
    static final int
    Show Comment nodes.
    static final int
    Show Document nodes.
    static final int
    Show DocumentFragment nodes.
    static final int
    Show DocumentType nodes.
    static final int
    Show Element nodes.
    static final int
    Show Entity nodes.
    static final int
    Show EntityReference nodes.
    static final int
    This bit instructs the iterator to show namespace nodes, which are modeled by DTM but not by the DOM.
    static final int
    Show Notation nodes.
    static final int
    Show ProcessingInstruction nodes.
    static final int
    Show Text nodes.
  • Method Summary

    Modifier and Type
    Method
    Description
    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 Details

    • SHOW_ALL

      static final int SHOW_ALL
      Show all Nodes.
      See Also:
    • SHOW_ELEMENT

      static final int SHOW_ELEMENT
      Show Element nodes.
      See Also:
    • SHOW_ATTRIBUTE

      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.
      See Also:
    • SHOW_TEXT

      static final int SHOW_TEXT
      Show Text nodes.
      See Also:
    • SHOW_CDATA_SECTION

      static final int SHOW_CDATA_SECTION
      Show CDATASection nodes.
      See Also:
    • SHOW_ENTITY_REFERENCE

      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.
      See Also:
    • SHOW_ENTITY

      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.
      See Also:
    • SHOW_PROCESSING_INSTRUCTION

      static final int SHOW_PROCESSING_INSTRUCTION
      Show ProcessingInstruction nodes.
      See Also:
    • SHOW_COMMENT

      static final int SHOW_COMMENT
      Show Comment nodes.
      See Also:
    • SHOW_DOCUMENT

      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.)
      See Also:
    • SHOW_DOCUMENT_TYPE

      static final int SHOW_DOCUMENT_TYPE
      Show DocumentType nodes.
      See Also:
    • SHOW_DOCUMENT_FRAGMENT

      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.)
      See Also:
    • SHOW_NOTATION

      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.
      See Also:
    • SHOW_NAMESPACE

      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.

      See Also:
    • SHOW_BYFUNCTION

      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.

      See Also:
  • Method Details

    • acceptNode

      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

      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.