Moddy Te'eni wrote:
David Bertoni wrote:
1. Can I use an XPath after its XPathConstructionContext is deleted? if
not,
can i use one global XPathConstructionContext to construct all my XPath
objects?
No. You can use a global XPathConstructionContext, but you will need to
serialize access to it if you are using multiple threads.
So I reckon I can have a global XPathConstructionContext and a global
XPathProcessorImpl, and protect initXPath() with a mutex; destroy the XPaths
only in the end.
David Bertoni wrote:
2. What is the difference between XPathProcessor::initXPath and
XPathProcessor::initMatchPattern ?
One creates an XPath instance from an XPath expression, and the other
creates an XPath instance from a match pattern, which is a limited
subset of XPath.
Thanks. I'll use initXPath(), then.
David Bertoni wrote:
3. Why does XPathEvaluator::evaluate calls reset() for its
executionContext
and XObjectFactory, and why does it sets the executionContext's
EnvSupport,
DOMSupport and XObjectFactory? What happens if I set it only once?
(assuming there is one evaluator for each input document)
It resets these for various reasons:
1. It resets the XPathExecutionContext and the XPathEnvSupport instance
because it doesn't make sense for state from one evaluation to leak into
another one.
Makes sense.
David Bertoni wrote:
2. It resets the XObjectFactory to prevent a large number of XObject
instances from accumulating. You can certainly change this if you want
to. For example, you might want to reset only after a certain number of
XPath expressions have been evaluated. This would mean you could keep a
number of evaluation results around between evaluations. The current
model forces the user to copy the result of the evaluation before
evaluating another expression.
Let me rephrase to make sure I understand:
XObjectFactory is one-per-thread, and when I reset it, it deletes all the
XObject instances it had created. If I want to keep the instance after the
reset, i need to copy it (using copy constructor, i presume) and keep it in
another place.
No, you cannot copy-construct an XObject. They are only available
through the XObjectPtr smart-pointer wrapper. To copy the value, you
need to determine the type of the XObject by calling XObject::getType().
After you've determined the type, you can call one of the typed
accessor functions, like boolean(), num(), string() or nodeset().
For example, consider the following snippet:
XObjectPtr result = ...
if (result.getType() == XObject::eTypeNodeSet)
{
NodeRefList copy = result.nodeset();
}
which copies the nodes from the result nodeset into a local NodeRefList
instance.
If you prefer a more "object-oriented" approach, you can use the member
function ProcessXObjectTypeCallback(), which will call back your
XObjectTypeCallback-derive class with the appropriate value for the type
of the XObject. You can search the code for more details.
I guess I can use two factories: one for temporary results (which I reset
frequently) and one for the results I need to keep.
It's easier just to make copies of the results into real types, instead
of creating new XObject to wrap them.
Dave
