<[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
