Hi Berin,
You're probably working in the mode were the wrapper is "pre-built," which
yields reasonable performance, but doesn't allow mapping from a Xerces node
to a Xalan node. The assumption is that you really wouldn't want to do
that since you already have Xalan nodes returned by the execution of the
XPath expression.
I think there was another request for this feature, so I'm pretty sure I
can make it an option. If you want to experiment, I suggest you modify the
wrapper layer yourself. Try this patch and see what happens:
cvs -z9 diff XercesDocumentWrapper.cpp (in directory
V:\xml-xalan\c\src\XercesParserLiaison\)
Index: XercesDocumentWrapper.cpp
===================================================================
RCS file:
/home/cvs/xml-xalan/c/src/XercesParserLiaison/XercesDocumentWrapper.cpp,v
retrieving revision 1.3
diff -r1.3 XercesDocumentWrapper.cpp
692a693,694
> mapNode = true;
>
*****CVS exited normally with code 1*****
The reason for avoiding the map is it consumes huge amounts of memory (we
really need to use a hash table instead of a map).
Dave
Berin Lautenbach
<[EMAIL PROTECTED] To: Xalan C Users
<[email protected]>
om.au> cc: (bcc: David N
Bertoni/Cambridge/IBM)
Subject: Re: Latest CVS
11/15/2002 01:19
PM
David,
Felt a bit of a dill last night - worked this out and (as I am using
XPath directly) am installing the functions into the
XPathEnvSupportDefault.
Only problem is I cannot seem to map nodes to and from Xerces<->Xalan.
The XPath is working properly, but when I use
theWrapperNavigator->mapNode(theXercesNode) I get back a NULL pointer.
When I go the opposite way (from a xalanNode fount in a nodelist return
item()) I get an exception.
But the mapping is working, because the XPath->exexcute(....) is finding
a number of nodes that looks to be about right.
I also know the xercesNode I want to find the xalanNode for was mapped,
because I have whatched the build treewalker find the node. (My problem
is once it gets inside the STL map it gets tricky to track.)
So I was wondering - is there anything I need to do to make this work?
I haven't got the source in front of me, but from memory I use a
xercesParserLiason->getDocument to get a document, and I then use the
ParserLiason to get a wrapper from which I build a wrapperNavigator. Is
there something important I have missed?
Cheers,
Berin
David N Bertoni/Cambridge/IBM wrote:
>
>
><[EMAIL PROTECTED]> wrote:
>
>
>>I am converting some code over to the "new" DOM implementation in Xerces,
>>so last night downloaded the latest (at that time) CVS tarball.
>>
>>Always a dangerous thing to do.....
>>
>>
>
>Livin' on the edge is fun!
>
>
>
>>Worked out how to move to the new *Wrapper classes, and had a whole lot
>>
>>
>of fun
>
>
>>and then came up with two questions.
>>
>>
>
>I hope it's working. It really does need more testing, and probably needs
>some more features added that were in the previous bridge.
>
>
>
>>Firstly - I notice that the wrappers treat DOMNode pointers as const.
>>
>>
>Makes
>
>
>>sense, but means that if I want to edit a returned node (e.g. from an
>>
>>
>XPath
>
>
>>selection) then I need to cast the return. Was there a reason for moving
>>
>>
>to
>
>
>>const (other than the obvious of it being a cleaner programming model for
>>
>>
>the
>
>
>>library)?
>>
>>
>
>Well, there's wasn't much point in const with the old smart-pointer DOM,
so
>this is the first time const made any sense. The reason is we try to stay
>const-correct within the engine, since XSLT doesn't allow modification of
>the source tree. Casting-off const shouldn't be any problem, so I felt it
>best to leave that to the user. It also helps insure we don't
>inadvertantly modify the underlying Xerces DOM, which would not be good.
>
>
>
>>Secondly - I install an additional XPath function, which now causes an
>>
>>
>exception.
>
>
>>Being curious I went through the code and realised the function table is
>>
>>
>in the middle
>
>
>>of being re-written (as I said - working from CVS code is always
>>
>>
>dangerous).
>
>Actually, it's finished being re-written. The new code enforces the
>content of the standard function table. We're no longer going to support
>installing functions into the standard table -- you should install them in
>the proper place. See the ExtensionFunction sample for more information.
>
>
>
>>I have a function that is context sensitive (the "here()" function
>>
>>
>defined in XML
>Signature). The easiest way to do this function is install an instance
>with the
>
>
>>appropriate node hard-coded and then un-install when the XPath selection
>>
>>
>is done.
>
>
>>This is fine under a static table until you hit multiple threads, at
>>
>>
>which point things
>
>
>>could get interesting. Different threads might want to install slightly
>>
>>
>different versions
>
>
>>of the same function at any given time.
>>
>>
>
>That's why there are per-instance functions tables. See
>XalanTransformer::installFunctionLocal() and
>XalanTransformer::installFunctionGlobal().
>
>Dave
>
>
>
>
