Russell,
Don't know if the following helps, it's extracted from some other code I have been working on:
XPathProcessorImpl xppi; // The processor XercesDOMSupport xds; XercesParserLiaison xpl; XPathEvaluator xpe; XPathFactoryDefault xpf; XPathConstructionContextDefault xpcc;
XalanDocument * xd;
// Map to Xerces Document (document) to Xalan
XalanDocument * xd; xd = xpl.createDocument(document);
// For performing mapping XercesDocumentWrapper *xdw = xpl.mapDocumentToWrapper(xd); XercesWrapperNavigator xwn(xdw);
...
LOTS OF STUFF TO SET UP AND GET READY FOR XPATH
...
XObjectPtr xObj = xp->execute(contextNode, pr, xpec);
// Now map to a list that others can use (naieve list at this time)
const NodeRefListBase& lst = xObj->nodeset();
int size = lst.getLength();
const DOMNode *item;
for (int i = 0; i < size; ++ i) { if (lst.item(i) == xd)
m_XPathMap.addNode(document);
else {
item = xwn.mapNode(lst.item(i));
m_XPathMap.addNode(item);
}
}Ignore the setup stuff the important part is the NodeRefListBase and reading the objects out of it.
xp is an XPath object that I set up in the middle (removed) section.
m_XPathMap is simly a list class that I have to hold the Xerces nodes. You could just as well use the map directly, but I need to return the
list to other classes that do not understand Xalan.
Hope it's usefull.
Cheers, Berin
Russell C. Hadley wrote:
Berin, Thanks! Are there any code samples of this kind of transformation around? Specificly mapping back and forth.
And your point about the ::Initialize() calls is well taken.
Thanks again. -R
Berin Lautenbach writes:
> Russell,
> > Not sure exactly what you are trying to do, but some thoughts.....
> > You want to be doing all the initialisation prior to using any > Xalan/Xerces objects. So :
> > XMLPlatformUtils::Initialize();
> XPathEvaluator::initialize();
> > Should be at the start of the code, and everything else should be in a > procedure/method call or embedded in its own code block. I.e.
> {
> XercesParserLiaison theParserLiaison;
> ...
> }
> > That way everything will be destroyed before you call terminate.
> > Assuming you pull the Xerces DOMDocument from the ParserLiaison, any > changes you make to it will not be mirrored in the XalanDOM - the map > between is (by default) built at the point when the document is created > and is not modified after that point.
> > I _think_ you can set it (using > XercesParserLiaison::setBuildWrapperNodes(false)) so that the maps are > not build until called on, and that may cause nodes that you have > created to be auto-added to the wrapper map. HOWEVER - I'd say this is > extremely unwise as modifications to existing nodes may not be detected > and deletions of nodes could get even more interesting.
> > If you want to modify the DOM structures and then perform an XPath > expression and continue, I've found it best to build and modify the > document using straight Xerces calls, wrap in Xalan when I want to do > XPath and then map back to Xerces and continue. If I need to do another > XPath - I re-map to ensure any changes I have done are caught.
> > Cheers,
> Berin
> > Russell C. Hadley wrote:
> > >Hi David,
> > Unsing the Xerces DOM all the function calls new complete but the
> >nodes returned from create element don't seem to be well formed (can't
> >be dumped with my dumper routine like everything else could) and none
> >of the updates appear in the output tree generated by the FormaterToXML
> >and FormatterTreeWalker.
> >
> >My initialization goes like this:
> >
> >// snip...
> >
> >XalanSourceTreeInit theSourceTreeInit;
> >XercesDOMSupport theDOMSupport;
> >
> >XercesParserLiaison theLiaison(theDOMSupport);
> >
> >XalanDocument *theDocument;
> >const LocalFileInputSource *theInputSource;
> >
> >XPathEvaluator theEvaluator;
> >
> >XalanNode* pTheContextNode;
> >
> >XMLPlatformUtils::Initialize();
> >
> >XPathEvaluator::initialize();
> >
> >pTheInputSource = new LocalFileInputSource(
> > c_wstr(XalanDOMString(filename.c_str())));
> >
> >// Parse the document...
> >theDocument =
> > theLiaison.parseXMLStream(*pTheInputSource);
> >
> >
> >// OK, let's find the context node...
> >pTheContextNode =
> > theEvaluator.selectSingleNode(
> > theDOMSupport,
> > theDocument,
> > XalanDOMString("/blah").c_str(),
> > theDocument->getDocumentElement());
> >
> >
> >Then I go on to create elements through the DOM document interface but
> >the nodes don't look bonafide and no changes seem to update in the DOM
> >when it's output by the Formatter. (the number of children of a given
> >node change though they can't be printed.)
> >
> >Any clue would be greatly appreciated. Or a pointer to a sample that
> >programattically adds nodes to an existant xerces DOM. (something
> >that uses createElement and appendChild) The cases I've been able to
> >track down through google (in java) arn't giving me a clue as to what
> >wires could be crossed.
> >
> >Thanks.
> >
> >-R
> >
> >David N Bertoni/Cambridge/IBM writes:
> > > > > > > > > > > > > > > Hi Russell,
> > > > > > > David,
> > > > One more thing. Can't seem to find the
> > > TransformToXercesDOM
> > > > sample (In either the Xerces or Xalan trees). Am I looking in the
> > > > right place? (or tree?) Thanks again. -R
> > > > > > You need the latest sources from CVS. If you've been getting your sources
> > > from the CVS repository, you should make sure you use the -d option when
> > > you update. If you're using a CVS tarball, get a new one.
> > > > > > Dave
> >
> >
> > > >
>
