CachedXPathAPIpublic class CachedXPathAPI extends Object The methods in this class are convenience methods into the
low-level XPath API.
These functions tend to be a little slow, since a number of objects must be
created for each evaluation. A faster way is to precompile the
XPaths using the low-level API, and then just use the XPaths
over and over.
This is an alternative for the old XPathAPI class, which provided
static methods for the purpose but had the drawback of
instantiating a new XPathContext (and thus building a new DTMManager,
and new DTMs) each time it was called. XPathAPIObject instead retains
its context as long as the object persists, reusing the DTMs. This
does have a downside: if you've changed your source document, you should
obtain a new XPathAPIObject to continue searching it, since trying to use
the old DTMs will probably yield bad results or malfunction outright... and
the cached DTMs may consume memory until this object and its context are
returned to the heap. Essentially, it's the caller's responsibility to
decide when to discard the cache. |
Fields Summary |
---|
protected XPathContext | xpathSupportXPathContext, and thus the document model system (DTMs), persists through multiple
calls to this object. This is set in the constructor. |
Constructors Summary |
---|
public CachedXPathAPI()Default constructor. Establishes its own {@link XPathContext}, and hence
its own {@link com.sun.org.apache.xml.internal.dtm.DTMManager}.
Good choice for simple uses.
Note that any particular instance of {@link CachedXPathAPI} must not be
operated upon by multiple threads without synchronization; we do
not currently support multithreaded access to a single
{@link com.sun.org.apache.xml.internal.dtm.DTM}.
xpathSupport = new XPathContext();
| public CachedXPathAPI(CachedXPathAPI priorXPathAPI)This constructor shares its {@link XPathContext} with a pre-existing
{@link CachedXPathAPI}. That allows sharing document models
({@link com.sun.org.apache.xml.internal.dtm.DTM}) and previously established location
state.
Note that the original {@link CachedXPathAPI} and the new one should
not be operated upon concurrently; we do not support multithreaded access
to a single {@link com.sun.org.apache.xml.internal.dtm.DTM} at this time. Similarly,
any particular instance of {@link CachedXPathAPI} must not be operated
upon by multiple threads without synchronization.
%REVIEW% Should this instead do a clone-and-reset on the XPathSupport object?
xpathSupport = priorXPathAPI.xpathSupport;
|
Methods Summary |
---|
public com.sun.org.apache.xpath.internal.objects.XObject | eval(org.w3c.dom.Node contextNode, java.lang.String str)Evaluate XPath string to an XObject. Using this method,
XPath namespace prefixes will be resolved from the namespaceNode.
return eval(contextNode, str, contextNode);
| public com.sun.org.apache.xpath.internal.objects.XObject | eval(org.w3c.dom.Node contextNode, java.lang.String str, org.w3c.dom.Node namespaceNode)Evaluate XPath string to an XObject.
XPath namespace prefixes are resolved from the namespaceNode.
The implementation of this is a little slow, since it creates
a number of objects each time it is called. This could be optimized
to keep the same objects around, but then thread-safety issues would arise.
// Since we don't have a XML Parser involved here, install some default support
// for things like namespaces, etc.
// (Changed from: XPathContext xpathSupport = new XPathContext();
// because XPathContext is weak in a number of areas... perhaps
// XPathContext should be done away with.)
// Create an object to resolve namespace prefixes.
// XPath namespaces are resolved from the input context node's document element
// if it is a root node, or else the current context node (for lack of a better
// resolution space, given the simplicity of this sample code).
PrefixResolverDefault prefixResolver = new PrefixResolverDefault(
(namespaceNode.getNodeType() == Node.DOCUMENT_NODE)
? ((Document) namespaceNode).getDocumentElement() : namespaceNode);
// Create the XPath object.
XPath xpath = new XPath(str, null, prefixResolver, XPath.SELECT, null);
// Execute the XPath, and have it return the result
// return xpath.execute(xpathSupport, contextNode, prefixResolver);
int ctxtNode = xpathSupport.getDTMHandleFromNode(contextNode);
return xpath.execute(xpathSupport, ctxtNode, prefixResolver);
| public com.sun.org.apache.xpath.internal.objects.XObject | eval(org.w3c.dom.Node contextNode, java.lang.String str, com.sun.org.apache.xml.internal.utils.PrefixResolver prefixResolver)Evaluate XPath string to an XObject.
XPath namespace prefixes are resolved from the namespaceNode.
The implementation of this is a little slow, since it creates
a number of objects each time it is called. This could be optimized
to keep the same objects around, but then thread-safety issues would arise.
// Since we don't have a XML Parser involved here, install some default support
// for things like namespaces, etc.
// (Changed from: XPathContext xpathSupport = new XPathContext();
// because XPathContext is weak in a number of areas... perhaps
// XPathContext should be done away with.)
// Create the XPath object.
XPath xpath = new XPath(str, null, prefixResolver, XPath.SELECT, null);
// Execute the XPath, and have it return the result
XPathContext xpathSupport = new XPathContext();
int ctxtNode = xpathSupport.getDTMHandleFromNode(contextNode);
return xpath.execute(xpathSupport, ctxtNode, prefixResolver);
| public com.sun.org.apache.xpath.internal.XPathContext | getXPathContext()Returns the XPathSupport object used in this CachedXPathAPI
%REVIEW% I'm somewhat concerned about the loss of encapsulation
this causes, but the xml-security folks say they need it.
return this.xpathSupport;
| public org.w3c.dom.traversal.NodeIterator | selectNodeIterator(org.w3c.dom.Node contextNode, java.lang.String str)Use an XPath string to select a nodelist.
XPath namespace prefixes are resolved from the contextNode.
return selectNodeIterator(contextNode, str, contextNode);
| public org.w3c.dom.traversal.NodeIterator | selectNodeIterator(org.w3c.dom.Node contextNode, java.lang.String str, org.w3c.dom.Node namespaceNode)Use an XPath string to select a nodelist.
XPath namespace prefixes are resolved from the namespaceNode.
// Execute the XPath, and have it return the result
XObject list = eval(contextNode, str, namespaceNode);
// Have the XObject return its result as a NodeSetDTM.
return list.nodeset();
| public org.w3c.dom.NodeList | selectNodeList(org.w3c.dom.Node contextNode, java.lang.String str)Use an XPath string to select a nodelist.
XPath namespace prefixes are resolved from the contextNode.
return selectNodeList(contextNode, str, contextNode);
| public org.w3c.dom.NodeList | selectNodeList(org.w3c.dom.Node contextNode, java.lang.String str, org.w3c.dom.Node namespaceNode)Use an XPath string to select a nodelist.
XPath namespace prefixes are resolved from the namespaceNode.
// Execute the XPath, and have it return the result
XObject list = eval(contextNode, str, namespaceNode);
// Return a NodeList.
return list.nodelist();
| public org.w3c.dom.Node | selectSingleNode(org.w3c.dom.Node contextNode, java.lang.String str)Use an XPath string to select a single node. XPath namespace
prefixes are resolved from the context node, which may not
be what you want (see the next method).
return selectSingleNode(contextNode, str, contextNode);
| public org.w3c.dom.Node | selectSingleNode(org.w3c.dom.Node contextNode, java.lang.String str, org.w3c.dom.Node namespaceNode)Use an XPath string to select a single node.
XPath namespace prefixes are resolved from the namespaceNode.
// Have the XObject return its result as a NodeSetDTM.
NodeIterator nl = selectNodeIterator(contextNode, str, namespaceNode);
// Return the first node, or null
return nl.nextNode();
|
|