You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2009/01/27 08:32:14 UTC
[RT] C3: Cleaning up SAX module
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?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] C3: Cleaning up SAX module
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> So in the end, using a ContentHandler that optionally implements
>> LexicalHandler looks like the simplest and most robust solution.
>>
>
> Yes, it seems better than relying on a not clearly specified assumption
>
Absolutely!
> (btw, if the sax result just has a content handler, this should be tried
> to be casted to a lexical handler as well, so we are in good company)
>
Indeed ;-)
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [RT] C3: Cleaning up SAX module
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> 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.
Ah interesting idea.
> 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.
Yepp
> 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.
Ah too bad :(
>
> So in the end, using a ContentHandler that optionally implements
> LexicalHandler looks like the simplest and most robust solution.
Yes, it seems better than relying on a not clearly specified assumption
(btw, if the sax result just has a content handler, this should be tried
to be casted to a lexical handler as well, so we are in good company)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] C3: Cleaning up SAX module
Posted by Sylvain Wallez <sy...@apache.org>.
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
Re: [RT] C3: Cleaning up SAX module
Posted by Andreas Pieber <an...@gmx.at>.
On Monday 02 February 2009 17:51:25 Carsten Ziegeler wrote:
> > 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.
I'm still the opinion that it may help newcomers to jump into cocoon if they
find a common interface-structure between all components. But on the other
hand a newcomer would work with the AbstractTransformers (mostly) and not
directly with COMPONENT-Producer/COMPONENT-Consumer...
Finally all my counter arguments for removing SAXC/SAXP are said and
discussed. I still like them but I've no problems with removing them :) . If
nobody else has any problems with it we could continue at
https://issues.apache.org/jira/browse/COCOON3-22
Thank you Carsten for taking the time to discuss this topic with me.
Andreas
Re: [RT] C3: Cleaning up SAX module
Posted by Carsten Ziegeler <cz...@apache.org>.
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
Re: [RT] C3: Cleaning up SAX module
Posted by Andreas Pieber <an...@gmx.at>.
First of all thank you very much for your detailed answer. I can rate most
ideas from an architectural point of view but what I'm really missing is a
year long hands on experience. I'm experiment very much with cocoon but
there's still so much to learn... So, thank you :)
On Thursday 29 January 2009 22:18:29 Carsten Ziegeler wrote:
> 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.
Yep, but you still know where to start, even if you have no exact idea of dom,
sax, stax, imaging, ...
>
> 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 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). 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.
An other option would be to let XProducer and XConsumer (maybe renaming them
to SAXProducer and SAXConsumer :) ) 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?
Andreas
>
> > 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
Re: [RT] C3: Cleaning up SAX module
Posted by Carsten Ziegeler <cz...@apache.org>.
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
Re: [RT] C3: Cleaning up SAX module
Posted by Andreas Pieber <an...@gmx.at>.
SEE https://issues.apache.org/jira/browse/COCOON3-22
Carsten Ziegeler commented on COCOON3-22:
-----------------------------------------
>Ok, having worked with the xml consumer interface for years now, I came to
the conclusion that things get much simpler if you just rely on content
handler
>It makes using the sax stuff much easier and more convenient - I don't think
that we need to keep the stax stuff and other impl in sync just for the sake
of having them in sync.
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 :)
>But please let's do this discussion in the mailing list - i've started an RT
some days ago about this topic and so far got only positive response (from
Sylvain)
I'm very sorry for that but the last days in January are always very painful
for Austrian students...
On Tuesday 27 January 2009 08:32:14 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?
> Carsten