1 | // |
2 | // NodeFilter.h |
3 | // |
4 | // Library: XML |
5 | // Package: DOM |
6 | // Module: NodeFilter |
7 | // |
8 | // Definition of the DOM NodeFilter interface. |
9 | // |
10 | // Copyright (c) 2004-2006, Applied Informatics Software Engineering GmbH. |
11 | // and Contributors. |
12 | // |
13 | // SPDX-License-Identifier: BSL-1.0 |
14 | // |
15 | |
16 | |
17 | #ifndef DOM_NodeFilter_INCLUDED |
18 | #define DOM_NodeFilter_INCLUDED |
19 | |
20 | |
21 | #include "Poco/XML/XML.h" |
22 | #include "Poco/XML/XMLString.h" |
23 | |
24 | |
25 | namespace Poco { |
26 | namespace XML { |
27 | |
28 | |
29 | class Node; |
30 | |
31 | |
32 | class XML_API NodeFilter |
33 | /// Filters are objects that know how to "filter out" nodes. If a NodeIterator |
34 | /// or TreeWalker is given a NodeFilter, it applies the filter before it returns |
35 | /// the next node. If the filter says to accept the node, the traversal logic |
36 | /// returns it; otherwise, traversal looks for the next node and pretends that |
37 | /// the node that was rejected was not there. |
38 | /// |
39 | /// The DOM does not provide any filters. NodeFilter is just an interface that |
40 | /// users can implement to provide their own filters. |
41 | /// |
42 | /// NodeFilters do not need to know how to traverse from node to node, nor do |
43 | /// they need to know anything about the data structure that is being traversed. |
44 | /// This makes it very easy to write filters, since the only thing they have |
45 | /// to know how to do is evaluate a single node. One filter may be used with |
46 | /// a number of different kinds of traversals, encouraging code reuse. |
47 | { |
48 | public: |
49 | enum |
50 | { |
51 | FILTER_ACCEPT = 1, |
52 | /// Accept the node. Navigation methods defined for NodeIterator or TreeWalker will return this node. |
53 | |
54 | FILTER_REJECT = 2, |
55 | /// Reject the node. Navigation methods defined for NodeIterator or TreeWalker |
56 | /// will not return this node. For TreeWalker, the children of this node will |
57 | /// also be rejected. NodeIterators treat this as a synonym for FILTER_SKIP. |
58 | |
59 | FILTER_SKIP = 3 |
60 | /// Skip this single node. Navigation methods defined for NodeIterator or TreeWalker |
61 | /// will not return this node. For both NodeIterator and TreeWalker, the children |
62 | /// of this node will still be considered. |
63 | }; |
64 | |
65 | enum WhatToShow |
66 | /// These are the available values for the whatToShow parameter used in TreeWalkers |
67 | /// and NodeIterators. They are the same as the set of possible types for Node, |
68 | /// and their values are derived by using a bit position corresponding to the |
69 | /// value of nodeType for the equivalent node type. If a bit in whatToShow is |
70 | /// set false, that will be taken as a request to skip over this type of node; |
71 | /// the behavior in that case is similar to that of FILTER_SKIP. |
72 | /// |
73 | /// Note that if node types greater than 32 are ever introduced, they may not |
74 | /// be individually testable via whatToShow. If that need should arise, it can |
75 | /// be handled by selecting SHOW_ALL together with an appropriate NodeFilter. |
76 | { |
77 | SHOW_ALL = 0xFFFFFFFF, |
78 | /// Show all Nodes. |
79 | |
80 | SHOW_ELEMENT = 0x00000001, |
81 | /// Show Element nodes. |
82 | |
83 | SHOW_ATTRIBUTE = 0x00000002, |
84 | /// Show Attr nodes. This is meaningful only when creating an iterator or tree-walker |
85 | /// with an attribute node as its root; in this case, it means that the attribute |
86 | /// node will appear in the first position of the iteration or traversal. Since |
87 | /// attributes are never children of other nodes, they do not appear when traversing |
88 | /// over the document tree. |
89 | |
90 | SHOW_TEXT = 0x00000004, |
91 | /// Show Text nodes. |
92 | |
93 | SHOW_CDATA_SECTION = 0x00000008, |
94 | /// Show CDATASection nodes. |
95 | |
96 | SHOW_ENTITY_REFERENCE = 0x00000010, |
97 | /// Show EntityReference nodes. |
98 | |
99 | SHOW_ENTITY = 0x00000020, |
100 | /// Show Entity nodes. This is meaningful only when creating an iterator or |
101 | /// tree-walker with an Entity node as its root; in this case, it means that |
102 | /// the Entity node will appear in the first position of the traversal. Since |
103 | /// entities are not part of the document tree, they do not appear when traversing |
104 | /// over the document tree. |
105 | |
106 | SHOW_PROCESSING_INSTRUCTION = 0x00000040, |
107 | /// Show ProcessingInstruction nodes. |
108 | |
109 | = 0x00000080, |
110 | /// Show Comment nodes. |
111 | |
112 | SHOW_DOCUMENT = 0x00000100, |
113 | /// Show Document nodes. |
114 | |
115 | SHOW_DOCUMENT_TYPE = 0x00000200, |
116 | /// Show DocumentType nodes. |
117 | |
118 | SHOW_DOCUMENT_FRAGMENT = 0x00000400, |
119 | /// Show DocumentFragment nodes. |
120 | |
121 | SHOW_NOTATION = 0x00000800 |
122 | /// Show Notation nodes. This is meaningful only when creating an iterator or |
123 | /// tree-walker with a Notation node as its root; in this case, it means that |
124 | /// the Notation node will appear in the first position of the traversal. Since |
125 | /// notations are not part of the document tree, they do not appear when traversing |
126 | /// over the document tree. |
127 | }; |
128 | |
129 | virtual short acceptNode(Node* node) = 0; |
130 | /// Test whether a specified node is visible in the logical view of a TreeWalker |
131 | /// or NodeIterator. This function will be called by the implementation of TreeWalker |
132 | /// and NodeIterator; it is not normally called directly from user code. (Though |
133 | /// you could do so if you wanted to use the same filter to guide your own application |
134 | /// logic.) |
135 | /// |
136 | /// Returns FILTER_ACCEPT, FILTER_REJECT or FILTER_SKIP. |
137 | |
138 | protected: |
139 | virtual ~NodeFilter(); |
140 | }; |
141 | |
142 | |
143 | } } // namespace Poco::XML |
144 | |
145 | |
146 | #endif // DOM_NodeFilter_INCLUDED |
147 | |