Hi Russell,
If you want to use the new classes, you'll have to get the latest code from
CVS, or build from a nightly CVS tarball.
Remember the "bridge" for the Xerces DOM was written to support XSLT, which
views the tree as immutable. It does not like it when you change the tree
and use the same "bridge," so the trick is to destroy the original bridge,
modify the document, then create a new one _after_ you've modified the
document:
1. build Xerces document
2. wrap document in bridge
3. search document
4. map Xalan nodes to Xerces nodes
5. destroy bridge
6. modify document through Xerces interface
7. repeat 2-6
Dave
"Russell C. Hadley"
<[EMAIL PROTECTED] To: Berin Lautenbach
<[EMAIL PROTECTED]>
design.com> cc: "Russell C.
Hadley" <[EMAIL PROTECTED]>, Xalan C Users
<[email protected]>, (bcc: David N Bertoni/Cambridge/IBM)
02/18/2003 02:24 PM Subject: Re: newbe:
books/better docs/better samples.
Berin,
Thanks for the reply. I'm still having problems
though.
I can't find the XercesDocumentWrapper and XercesWrapperNavigator you
mentioned in the online docs. So I'm working with the
XercesDocumentBridge and XercesBridgeNavigator (just because they're
the closest names). What I'm still finding is that no new nodes I've
added are appearing in the DOM. I can't seem to get the tinker toys
to go together. Some conceptual peice seems to be missing. I go from
XercesDOMSupport => XercesParserLiaison => XercesDocumentBridge =>
XercesDocumentNavigator and the DOM interface at every step will not
let me add nodes. The experiment I wrote in Xerces works like one
would expect but the moment I bring Xalan into the picture I can't
seem to apply changes to the DOM. (tearing out hair...)
-R
Berin Lautenbach writes:
> 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
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
>
