| Fields Summary |
|---|
| public static final int | SHOW_ALLShow all Nodes. |
| public static final int | SHOW_ELEMENTShow Element nodes. |
| public static final int | SHOW_ATTRIBUTEShow 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. |
| public static final int | SHOW_TEXTShow Text nodes. |
| public static final int | SHOW_CDATA_SECTIONShow CDATASection nodes. |
| public static final int | SHOW_ENTITY_REFERENCEShow 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. |
| public static final int | SHOW_ENTITYShow 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. |
| public static final int | SHOW_PROCESSING_INSTRUCTIONShow ProcessingInstruction nodes. |
| public static final int | SHOW_COMMENTShow Comment nodes. |
| public static final int | SHOW_DOCUMENTShow 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.) |
| public static final int | SHOW_DOCUMENT_TYPEShow DocumentType nodes. |
| public static final int | SHOW_DOCUMENT_FRAGMENTShow 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.) |
| public static final int | SHOW_NOTATIONShow 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. |
| public static final int | SHOW_NAMESPACEThis 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 {@link org.w3c.dom.traversal.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. |
| public static final int | SHOW_BYFUNCTIONSpecial bit for filters implementing match patterns starting with
a function. Make sure this does not conflict with
{@link org.w3c.dom.traversal.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. |
| Methods Summary |
|---|
| 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.
|
| 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.
|
