RE: returning xml nodes from extensions functions

[Mark Weaver <ma...@npsl.co.uk>]

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).

class XalanDynamicNodeSetBuilder : public XalanDynamicBuilder ...
class XalanDynamicResultTreeFragmentBuilder : public XalanDynamicBuilder ...

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).

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.

Thanks,

Mark

> -----Original Message-----
> From: David N Bertoni/Cambridge/IBM [mailto:david_n_bertoni@us.ibm.com]
> Sent: 31 October 2002 18:00
> To: xalan-c-users@xml.apache.org
> Subject: RE: returning xml nodes from extensions functions
>
>
>
>
>
>
>
> Hi Mark,
>
> > > Hi Mark,
> > >
> > > Sorry, I've been incredibly busy the week or so, so I
> apologize for not
> > > responding sooner.
> >
> > No problem.  Hope things are calmer for you now.
>
> Yes, I'm on "vacation," so I'm writing code.  Wait, that's what I do when
> I'm _not_ on vacation...
>
> > >    1. I think two different classes, one which does the node-set, and
> > >    another which does RTFs would be better than one class with a
> > >    constructor parameter.  What do you think?
> >
> > Yes, that sounds like a better idea.
> >
> > >    2. We should use the SAX2 ContentHandler, LexicalHandler, and
> > > DTDHandler
> > >    interfaces, instead of Xalan's proprietary FormatterListener.
> >
> > I will change this over.  Presumably since we are building a
> XalanSourceTree
> > we will simply return a XalanSourceTreeContentHandler.
>
> You'll have to do it using the SAX2 intefaces, because
> XalanSourceTreeContentHandler is not available at that level in the
> architecture.  Also, it's not an abstract base class, so it's not good for
> use in interfaces.
>
> > >    3. We need an abstract base class that defines the interfaces, then
> we
> > >    can derive the implementation classes from them.  I'd like to get
> that
> > >    set first, so we know we've got the design right.
> >
> > The interface would be pretty much the same:
> >
> > class XalanDynamicBuilder {
> >            XalanSourceTreeContentHandler *getContentHandler()=0;
> >            XObjectPtr getXObject()=0;
> > };
> >
> > with maybe a 'reset' that allows the builder to be passed back to the
> > execution context.
>
> We should probably wrap it in the same style as the other "auto_ptr-like"
> classes already in the interfaces.  That way, the destruction/reset is
> automatic.  See things like XPathExecutionContext::
> GetAndReleaseCachedString, etc.  You may not like my naming style, so feel
> free to call it what you like.
>
> > >
> > > Actually, I think the document is owned by the fragment.  This is
> already
> > > done in the implementation of ResultTreeFrag in the XSLT subsystem.
> > >
> > > Ahh, I should have been clearer about this, and I apologize for not
> doing
> > > so.  This should not live in XPathExecutionContext.  The implemenation
> in
> > > XPathExecutionContext default should simply return 0 when
> someone wants
> to
> > > create one of these.  This is consistent -- there is functionality we
> just
> > > don't support when just using the XPath subsystem.  This does make
> sense,
> > > since XPath has no construction semantics, and so those using
> XPath for
> > > queries are not likely to need result tree fragments.
> >
> > Right, that makes things quite a bit simpler as the builder classes can
> work
> > with the StylesheetExecutionContext which already contains a bunch of
> > allocators that can be used.
> >
> > > I hope this helped!  ;-)  Now, I hope I won't disappear like that
> again...
> >
> > Definitely!  Let me know if i've got it right this time, and I'll go and
> > finish it off.
>
> Sounds good so far.  However, we may need to tweak it once it's built and
> in production.
>
> Yikes, code going into Xalan that wasn't wriiten by me!  That hasn't
> happened for a long time.  Can I cope, being the ultimate control-freak?
> ;-)
>
> > Thanks,
> >
> > Mark
>
> And thank you...
>
> Dave
>
>

RE: returning xml nodes from extensions functions

[David N Bertoni/Cambridge/IBM <da...@us.ibm.com>]

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