Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 46331 invoked from network); 20 Mar 2004 15:23:05 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 20 Mar 2004 15:23:05 -0000 Received: (qmail 704 invoked by uid 500); 20 Mar 2004 15:22:57 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 653 invoked by uid 500); 20 Mar 2004 15:22:56 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 638 invoked from network); 20 Mar 2004 15:22:56 -0000 Received: from unknown (HELO mail.gmx.net) (213.165.64.20) by daedalus.apache.org with SMTP; 20 Mar 2004 15:22:56 -0000 Received: (qmail 11765 invoked by uid 65534); 20 Mar 2004 15:22:57 -0000 Received: from a183069.studnetz.uni-leipzig.de (EHLO gmx.de) (139.18.183.69) by mail.gmx.net (mp017) with SMTP; 20 Mar 2004 16:22:57 +0100 X-Authenticated: #3483660 Message-ID: <405C61EE.9020007@gmx.de> Date: Sat, 20 Mar 2004 16:23:26 +0100 From: Joerg Heinicke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en-gb, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: AbstractXMLProducer patch consequences References: <20040318183313.43612.qmail@minotaur.apache.org> <405A0DE1.3070900@gmx.de> <405B90D7.6000604@reverycodes.com> In-Reply-To: <405B90D7.6000604@reverycodes.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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