cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject AbstractXMLProducer patch consequences
Date Thu, 18 Mar 2004 21:00:17 GMT
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

Mime
View raw message