cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: [rant] please backport bugfixes to 2.1!
Date Wed, 03 Nov 2004 17:48:13 GMT
On Wed, Nov 03, 2004 at 06:29:46PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
> >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.

Ok, but I predict Marc will be unhappy ;)

> >
> >   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.

Ok, thanks for explaining.

> >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.

Please go ahead and commit, then I will comment if necessary.

> 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 
> states

Yeah, I did not think that design was ready either...but we may need
to expand widget states (tm) a little bit, but I will see after your

> - 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.

There is reason to this madness, if you will just bear with me
for a bit.  I will hold off on porting that to BRANCH_2_1_X.

I have a plan, an experiment, but if it is too disruptive for
the dev line (svn trunk) then I could move it to the whiteboard.
It involves compiled templates and transformers (yes, I figured
out an efficient way to compile and cache transformer-templates)
with fairly human-friendly syntax, view "widgets", and parallel
structure between the binding, model, and templates, including
things like having choose/when being in all three (as a more
functional, flexible replacement for union/case).  WDYT, do I
need to move this effort to the whiteboard? (not a vote ;)

--Tim Larson

View raw message