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
--
Carsten Ziegeler
cziegeler@apache.org
|