cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [C2] [2.1-dev] proposed changes to the Source interface
Date Fri, 24 Aug 2001 10:11:01 GMT
Ovidiu Predescu wrote:
> On Thu, 23 Aug 2001 10:06:31 +0200, Sylvain Wallez <>
>>Ovidiu Predescu wrote:
>>>On Thu, 16 Aug 2001 10:52:25 +0200, Sylvain Wallez <>
>>>>>public interface XMLFragment
>>>>> void toSAX(ContentHandler handler) throws SAXException;
>>>>> void toSAX(XMLConsumer consumer) throws SAXException;
>>>>> void toDOM(Node node) throws Exception;
>>>>Be careful with XMLFragment : it's the only class that is common to both
>>>>Cocoon1 and Cocoon2. This was meant to facilitate the transition by
>>>>allowing people to represent their application objects with an
>>>>XMLFragment that would be handled equally by C1 and C2.
>>>Do you think is OK if I add the toSAX(XMLConsumer) method to
>>Well, I think we should avoid this : if XMLFragment is modified, this 
>>means "legacy" XMLFragment implementations coming from C1 apps won't run 
>>in C2.
>>What about a new interface that extends XMLFragment with 
>>toSAX(XMLConsumer) ? Suggested names : ExtendedXMLFragment, XMLizable.
>>Or we could consider XMLFragment as purely legacy (i.e. support it but 
>>deprecate it), and have the new interface be independent with only 
>>toSAX(XMLConsumer), since toDOM() is useless for C2 :
>>public interface XMLizable {
>>   void toSAX(XMLConsumer consumer) throws SAXException;
> Sounds like a good idea. I like XMLizable better, so lets go with this
> one. Except that we would need to have toSAX(ContentHandler) as well
> in this interface:
> public interface XMLizable {
>    void toSAX(ContentHandler handler) throws SAXException;
>    void toSAX(XMLConsumer consumer) throws SAXException;
> }
> Other thoughts?
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 

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 ?
Sylvain Wallez
Anyware Technologies -

To unsubscribe, e-mail:
For additional commands, email:

View raw message