Re: Latest CVS

[Berin Lautenbach]

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