cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: AbstractXMLProducer patch consequences
Date Sat, 20 Mar 2004 00:31:19 GMT
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



Mime
View raw message