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:[EMAIL PROTECTED]
> Sent: 31 October 2002 18:00
> To: [email protected]
> 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
>
>
