cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [RT] C3: Cleaning up SAX module
Date Thu, 29 Jan 2009 21:18:29 GMT
Andreas Pieber wrote:
> I really like the idea of having a common base architecture between all 
> components (sax, stax, ...). I'm not sure if we really have to hold them in 
> sync since its more a basic architectural decision to rely on an a special 
> Producer/Consumer interface than a syncing task. But I just wanted to point 
> out that we sacrifice this basic architecture (existing at the moment) if we 
> remove XConsumer/XProducer. I doesn't want to say that we should not do it, if 
> there are more advantages than drawbacks :)
Ok, usually I'm for a unified architecture if it's possible. But in this
case I think it doesn't give any advantage. The xml handling differs a
lot between dom, sax and stax. So even if you find interface with
similar names (xyzProducer, xyzConsumer) they are completly different
and have to be used differently when it comes to implementing own
components.

Years ago we decided in Cocoon to introduce the XMLConsumer interfaces.
During the years, it rather proofed that this interface creates
unnecessary trouble. For example you get some third party stuff
implementing just content handler, you have to wrap it first. Or if you
want to write general sax components that work with and without Cocoon,
you have a dependency on Cocoon just for this interface.
In the last years I followed the approach the jaxp api follows: just use
content handler, and check if the object also implements content
handler. This really simplifies the impl and the handling, makes
integrating other stuff easy and doesn't create unnecessary dependencies.

> I'm very sorry for that but the last days in January are always very painful 
> for Austrian students... 
No problem :) we're now having this discussion here and that's all that
counts.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message