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.
WDYT?
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
--
Sylvain Wallez - http://bluxte.net
