cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] C3: Cleaning up SAX module
Date Mon, 02 Feb 2009 16:51:25 GMT
Andreas Pieber wrote:
> I'm not convinced that removing XProducer and XConsumer will resolve all 
> problems described by you since you still need a reference to Cocoon (e.g. for 
> PipelineComponent and Producer/Consumer). 
Yes, you got me :)

> One possibility to get rid of all 
> references could be the spring framework. POJOs with a ContentHandler and an 
> setConsumer(Object) method could be (very easily) described in XML and wrapped 
> at runtime to "real" PipelineComponents.
Yes, but if I really want to do this, I can do this regardless if we
have SAXConsumer (XMLConsumer) or not.

> An other option would be to let XProducer and XConsumer (maybe renaming them 
> to SAXProducer and SAXConsumer :) ) 
(Yes, we should rename them and I think we already agreed on this on)

> and just weaken the conditions. The 
> components simply check for an ContentHandler/LexicalHandler as they require. 
> With this approach you let the decision to the developer if he like to simply 
> inherit from the X-Interfaces and has an SAXPipelineComponent, a 
> ContentHandler and so on at once or do it on his own. WDYT about this 
> approach? 
Hmm, not sure :) Seems like a wrong compromise to me :) Either we really
want these interfaces for symmetrical reasons (which I think is not
worth doing it and given the different between the formats itself
doesn't help) or if we want the simplest approach for each type (xml,
dom, stax). I would vote for the second approach.

Carsten Ziegeler

View raw message