Hi Mark,
> OK, one more stab before this gets somewhere ;)
>
> I'm happy with the two class/base class concept, i.e.
>
> class XalanDynamicBuilder {
>
> void reset()=0;
>
> ContentHandler *getContentHandler()=0;
> LexicalHandler *getLexicalHandler()=0;
> DocumentHandler *getDocumentHandler()=0;
>
> XObjectPtr getXObject()=0;
> }
>
> Not sure what to do with the DTD handler here as that claims to be from
the
> SAX tree (and it doesn't seem terribly useful in this context anyway).
We shouldn't support DocumentHandler at all, since it's from the SAX1, and
it doesn't support namespaces. DTDHandler is necessary in SAX2, because
comments can be generated from within the DTD, and we have to exclude those
from the tree. Someone could create one of these and use the Xerces SAX2
parser to parse a file. They don't really need to do that, but why have
some special case situation with this class that doesn't work?
> As for GetAndReleasedCached <X>, this seems to be getting slightly messy,
as
> I would have to spawn an extra 2 classes to cope. I would say that
better
> is to have
> template <class T> GetAndReleaseCachedObject<T> {
> }
>
> calling XPathExecutionContext::releaseObject(T).
Yes, I'd prefer to do that, but I'm not sure all of our supported compilers
will handle a nested class template correctly. If they will, it would be
great to use this instead of the individual classes everywhere.
> I'm also interested in what the constraints are in building
XalanSourceTrees
> out of order; I do this currently (and it is more convienient than SAX in
> that respect), by building subtree fragments and assembling them together
> later on down the line. This doesn't seem to cause any problems, but I'd
be
> interested to know if this is going to break anything.
This is a disaster waiting to happen. Nodes are indexed in document order
as they're created, so if you assemble them out of order, then, when the
XPath engine puts them into document order using the indexes, it will not
be correct.
Dave
