cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [rant] please backport bugfixes to 2.1!
Date Wed, 03 Nov 2004 17:29:46 GMT
Tim Larson wrote:

>On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
>>Unusual for me, but time for a rant: I wrote the new CForms widget state 
>>feature in 2.1 and tried to port it to 2.2.
>>There are a number or *bug fixes* or minor new features that only exist 
>>in 2.2. Why aren't they ported also to 2.1?
>>Please, please, consider upgrading both branches at the same time. There 
>>will be some time before 2.2 is out and not everybody runs a snapshot of 
>>Grmbl... lost 2 hours this morning to do the merge, and finally reverted 
>>all :-(
>Very sorry that you lost time :(  I had not ported my changes
>to 2_1_x yet because I was not sure they were ready, but
>addmittedly there were some bugfixes included that I should
>have ported immediately.
>I am working on the port now and have it almost finished,

Buhooo... I missed your post and am also almost finished :-(((

>but I have a few questions about some recent changes that
>the commit comments did not make clear to me:
>    From: public Widget getParent()
>    To:   public final Widget geParent()

I had a bug while writing widget states because Repeater.RepeaterRow was 
redefining getParent() while I was using this.parent. So I made it final 
in order to be able to use this.parent throughout AbstractWidget.

>    From: super validate
>    To:   super validate && widget != null

That's "value != null". This check is required as "old-style validators" 
(the ones that were inside fd:datatype) assume a non-null value and this 
was therefore leading to NPEs.

>    In inner class RepeaterRow
>      From: getParent() returns Repeater.this and
>            setParent() throws a RuntimeException
>      To:   setParent(Repeater.this)
>      (This seems to be caused by the AbstractWidget
>      change above.)


>Could you explain what these changes are for, and then
>I can finish the porting.

Mmmh... I nearly finished it on my side... how do we proceed? I'm ready 
to finish that job if you don't mind.

Note that there are some new features in 2.2 that I wouldn't like to be 
ported now to 2.1 as I'm not very happy with them and would like some 
discussion about them:
- the get/setProcessRequest() stuff which seems to overlap with widget 
- the new "choose/when" statement in EffectWidgetReplacingPipe: for 
complex control structures, we have template languages like JTXG and 
XSP. It doesn't seem good to me that every transformer reinvents it's 
own control structure language.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message