cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] C3: Cleaning up SAX module
Date Tue, 27 Jan 2009 16:22:48 GMT
Carsten Ziegeler wrote:
> Hi,
> I think we can reduce the number of interfaces in the SAX module by just
> removing XMLProducer and XMLConsumer. XMLProducer is just a marker
> interface combining Producer and SAXPipelineComponent, so we can just
> remove it.
> XMLConsumer combines LexicalHandler, ContentHandler and Consumer. I
> think we can remove this and just rely on ContentHandler for chaining
> sax components. When sax components are chained, they can simply check
> if the next component implements LexicalHandler as well or not. With
> this simple improvement we can also remove the XMLConsumerAdapter.

Yup, it's easier to wrap separate ContentHander and LexicalHandler 
objects into a simple wrapper implementing both interfaces rather than 
having to deal with a Cocoon-specific XMLConsumer everywhere.

Now we should also consider javax.xml.sax.SAXResult that holds a 
ContentHandler and an optional LexicalHandler, and has an interesting 
SystemId property that could be used to propagate a base URI from one 
component to the next one without relying on an external resolver context.

And the fact that SAXResult _holds_ the handlers rather than 
implementing the interfaces can in many cases avoid a level of wrapping 
as the one mentioned above.

But the properties in SAXResult are mutable and the javadocs don't 
specify when these properties can change, i.e. if a producer should call 
getHandler() every time it needs to produce events of if the value can 
be kept for the whole stream of events, even if I think the second case 
is the most often used.

So in the end, using a ContentHandler that optionally implements 
LexicalHandler looks like the simplest and most robust solution.


Sylvain Wallez -

View raw message