> I wonder if there will be some problems with the 2 toSAX() methods
> considering that XMLConsumer extends ContentHandler, and that most
> often, an XMLConsumer is stored in separate ContentHandler and
> LexicalHandler variables, meaning you no longer have an XMLConsumer
> variable.
>
> Since most implementations of XMLizable won't produce lexical events and
> thus will only use ContentHandler methods, wouldn't it be simpler for
> XMLizable to have only toSAX(contentHandler) and let the few
> implementations that need it test if the handler is actually instance of
> XMLConsumer (see example in
> org.apache.cocoon.components.sax.XMLByteStreamFragment) ?
>
> That way, we can have XMLFragment extend XMLizable and still be
> compatible with the Cocoon1 definition.
>
> So that we can try it, I've added XMLizable in the 2.1 CVS with only
> toSAX(ContentHandler) and updated the XSP engine so that <xsp:expr>
> accepts XMLizables instead of XMLFragments.
>
> Thoughts about this ?
I think this sounds reasonable. We have been using the XMLFragment
interface quite a lot. I cannot see a good reason to have both
in the interface...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
