You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2004/03/18 22:00:17 UTC
AbstractXMLProducer patch consequences
On 18.03.2004 19:33, joerg@apache.org wrote:
> joerg 2004/03/18 10:33:13
>
> Modified: src/java/org/apache/cocoon/xml AbstractXMLProducer.java
> Log:
> fixed bug 27678, thanks to Peter Brant: setConsumer() calls setContentHandler() + setLexicalHandler()
> public void setConsumer(XMLConsumer consumer) {
> this.xmlConsumer = consumer;
> - this.contentHandler = consumer;
> - this.lexicalHandler = consumer;
> + setContentHandler(consumer);
> + setLexicalHandler(consumer);
> }
Unfortunately this change breaks XSP. I debugged a bit into to see what
happens. The reason is in CocoonMarkupLanguage.PreProcessFilter:
(Comments /* */ are added by myself.)
public class PreProcessFilter extends AbstractXMLPipe {
protected AbstractXMLPipe filter;
public PreProcessFilter (AbstractXMLPipe filter) {
/* filter is a CocoonTransformerChainBuilderFilter */
this.filter = filter;
/* calls the AbstractXMLProducer implementation */
super.setConsumer(this.filter);
}
public void setConsumer(XMLConsumer consumer) {
// Add consumer after filter
/* this is never called */
this.filter.setConsumer(consumer);
}
public void setContentHandler(ContentHandler handler) {
/* this is called from outside: LogicsheetCodeGenerator, line 108 */
this.filter.setContentHandler(handler);
}
public void setLexicalHandler(LexicalHandler handler) {
/* this is never called */
this.filter.setLexicalHandler(handler);
}
}
From an object oriented polymorphism POV this looks really hacky.
Something like "because we have to provide an implementation for others
in a different way, lets use the super implementation that provides the
correct implementation for us".
If the changed/patched AbstractXMLProducer is in use,
setContentHandler() and setLexicalHandler() are called with this.filter
as parameter and the code generation fails. If the implementation of
both methods is removed, you can not set the handlers of the filter.
Of course we can just revert the patch, but the above is still what I
would call hacky.
WDYT?
Joerg
Re: AbstractXMLProducer patch consequences
Posted by Joerg Heinicke <jo...@gmx.de>.
On 20.03.2004 01:31, Vadim Gritsenko wrote:
>>> Modified: src/java/org/apache/cocoon/xml AbstractXMLProducer.java
>>> Log:
>>> fixed bug 27678, thanks to Peter Brant: setConsumer() calls
>>> setContentHandler() + setLexicalHandler()
>>
>>> public void setConsumer(XMLConsumer consumer) {
>>> this.xmlConsumer = consumer;
>>> - this.contentHandler = consumer;
>>> - this.lexicalHandler = consumer;
>>> + setContentHandler(consumer);
>>> + setLexicalHandler(consumer);
>>> }
>>
>>
>>
>> Unfortunately this change breaks XSP. I debugged a bit into to see
>> what happens. The reason is in CocoonMarkupLanguage.PreProcessFilter:
...
>> From an object oriented polymorphism POV this looks really hacky.
>> Something like "because we have to provide an implementation for
>> others in a different way, lets use the super implementation that
>> provides the correct implementation for us".
>>
>> If the changed/patched AbstractXMLProducer is in use,
>> setContentHandler() and setLexicalHandler() are called with
>> this.filter as parameter and the code generation fails. If the
>> implementation of both methods is removed, you can not set the
>> handlers of the filter.
>>
>> Of course we can just revert the patch, but the above is still what I
>> would call hacky.
>>
>> WDYT?
>
> Option 1: Do not call super.setConsumer() above, use
> super.setContent/LexicalHandler.
Chose this one. Though it does not solve my feelings above. Must this be
by design? Couldn't this.filter in PreProcessFilter given to
LogicsheetCodeGenerator so that it can call setConsumer() on this object
directly? Or does this break other parts of the design. I found it
really confusing ...
> And question, are there more places like this?
I don't hope so.
> PS I use a bit of XSP; JXTG currently does not yet offer everything you
> need...
I don't want to remove XSP in near future ;)
Joerg
Re: AbstractXMLProducer patch consequences
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joerg Heinicke wrote:
> On 18.03.2004 19:33, joerg@apache.org wrote:
>
>> joerg 2004/03/18 10:33:13
>>
>> Modified: src/java/org/apache/cocoon/xml AbstractXMLProducer.java
>> Log:
>> fixed bug 27678, thanks to Peter Brant: setConsumer() calls
>> setContentHandler() + setLexicalHandler()
>
>
>> public void setConsumer(XMLConsumer consumer) {
>> this.xmlConsumer = consumer;
>> - this.contentHandler = consumer;
>> - this.lexicalHandler = consumer;
>> + setContentHandler(consumer);
>> + setLexicalHandler(consumer);
>> }
>
>
> Unfortunately this change breaks XSP. I debugged a bit into to see
> what happens. The reason is in CocoonMarkupLanguage.PreProcessFilter:
>
> (Comments /* */ are added by myself.)
>
> public class PreProcessFilter extends AbstractXMLPipe {
>
> protected AbstractXMLPipe filter;
>
> public PreProcessFilter (AbstractXMLPipe filter) {
> /* filter is a CocoonTransformerChainBuilderFilter */
> this.filter = filter;
> /* calls the AbstractXMLProducer implementation */
> super.setConsumer(this.filter);
> }
>
> public void setConsumer(XMLConsumer consumer) {
> // Add consumer after filter
> /* this is never called */
> this.filter.setConsumer(consumer);
> }
>
> public void setContentHandler(ContentHandler handler) {
> /* this is called from outside: LogicsheetCodeGenerator, line 108 */
> this.filter.setContentHandler(handler);
> }
>
> public void setLexicalHandler(LexicalHandler handler) {
> /* this is never called */
> this.filter.setLexicalHandler(handler);
> }
> }
>
> From an object oriented polymorphism POV this looks really hacky.
> Something like "because we have to provide an implementation for
> others in a different way, lets use the super implementation that
> provides the correct implementation for us".
>
> If the changed/patched AbstractXMLProducer is in use,
> setContentHandler() and setLexicalHandler() are called with
> this.filter as parameter and the code generation fails. If the
> implementation of both methods is removed, you can not set the
> handlers of the filter.
>
> Of course we can just revert the patch, but the above is still what I
> would call hacky.
>
> WDYT?
Option 1: Do not call super.setConsumer() above, use
super.setContent/LexicalHandler.
Option 2: Revert patch, fix javadoc
And question, are there more places like this?
PS I use a bit of XSP; JXTG currently does not yet offer everything you
need...
Vadim