djohn...@desknetinc.com wrote:
I've looked over the relevant samples and documentation, but haven't
found enough information. Any pointers to useful doc or samples would
be appreciated.
In fact, the samples and documentation lead me to additional questions:
From the XercesParserLiaison API, it would appear that I need
buildMaps=true, and possibly buildWrapper=true, in order to map the
Xerces DOMNode to its Xalan counterpart, but I don't see any method that
uses the map to give me the Xalan node from the Xerces node.
buildWrapper determines if the wrapper is built all at once or as each
node is accessed. And although it's not explicitly documented, I
believe asking for the maps will force the wrapper to be built.
To get at mapping information, you must cast the XalanDocument pointer
to the implementation type of XercesDocumentWrapper, and include the
header file for that class:
DOMNode* func(XalanDocument* doc, XalanNode* node)
{
const XercesDocumentWrapper* wrapper = static_cast<const
XercesDocumentWrapper*>(doc);
return wrapper->mapNode(node);
}
XalanNode* func(XalanDocument* doc, DOMNode* node)
{
const XercesDocumentWrapper* wrapper = static_cast<const
XercesDocumentWrapper*>(doc);
return wrapper->mapNode(node);
}
What is the overhead of enabling buildWrapper and buildMaps?
Are they kept current across modifications to the original Xerces DOM?
The overhead is the memory required to maintain the wrapper and the hash
maps of the nodes. This can be significant if your document is large.
The wrapper and the maps are _not_ maintained across modifications to
the Xerces DOM. Not only would it be complicated, but I'm not sure how
it's possible to track modifications to the Xerces DOM instance.
From a sample, I have:
// Set up our link between the Xerces and Xalan DOMs. (doc is a
Xerces DOMDocument*)
XercesDOMSupport support;
XercesParserLiaison liaison(support);
XercesDOMWrapperParsedSource src(doc, liaison, support);
XalanDocument* xalanDoc = src.getDocument( );
Yet it would appear from the API that I could pare that down to:
// Set up our link between the Xerces and Xalan DOMs. (doc is a
Xerces DOMDocument*)
XercesDOMSupport support;
XercesParserLiaison liaison(support);
XalanDocument* xalanDoc = liaison.createDocument(doc, false, true,
true);
Are these equivalent, or is there a reason to use one over the other?
If I use XercesDOMWrapperParsedSource, do I need to set properties of
liaison first to force mapping and wrapping?
You would only want to use a XercesDOMWrapperParsedSource if you plan to
use the XalanTransformer class to transform the document. Otherwise, if
you're using only the XPathEvaluator API, you can simply use the
XalanDocument instance returned from XercesParserLiaison::createDocument().
If you want the maps to be built, you must call
liaison.setBuildMaps(true) before you create the
XercesDOMWrapperParsedSource instance. XercesDOMWrapperParsed source
_forces_ the "threadSafe" and "buildWrapper" parameters to be true when
it calls XercesParserLiaison::createDocument().
If the overhead is significant to wrapping and/or mapping, especially if
the entire document is processed, I would want to cache them for later
use evaluating other XPaths.
Which of the associated objects is sufficient to cache? liason and
xalanDoc? support?
The XercesParserLiaison owns the XalanDocument instance, so you must
keep that alive. The XalanDocument instance it creates owns the wrapper
and the maps, so you must keep that alive as well. Note that caching is
useless if you plan to modify the Xerces DOM instance.
And finally, how do I map a Xerces DOMNode/DOMElement to a Xalan node to
use as the context for XPath evaluation?
See the small function snippets I provided previously.
Dave
