Ovidiu Predescu wrote:
> On Thu, 23 Aug 2001 10:06:31 +0200, Sylvain Wallez <[EMAIL PROTECTED]>
>wrote:
>
>
>>Ovidiu Predescu wrote:
>>
>>>Sylvain,
>>>
>>>On Thu, 16 Aug 2001 10:52:25 +0200, Sylvain Wallez
><[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
>>>>>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
>>>XMLFragment?
>>>
>>>Greetings,
>>>
>>>
>>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
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 ?
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
