cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [rant] please backport bugfixes to 2.1!
Date Wed, 03 Nov 2004 18:05:49 GMT
Tim Larson wrote:

>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:
>>>
>>>AbstractWidget.java
>>>  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 ;)
>  
>

Why? Does he have special widgets that redefine getParent(). If that's 
the case, we can remove the "final" and replace "this.parent" by 
"getParent()".

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

Okay!

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

Ok. Something that's seem more and more necessary to me is an "output" 
state that would sit between "disabled" and "invisible", in order to 
render widgets as text and not as disabled inputs without having to use 
styling type="output".

>>- 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 ;)
>  
>

You already told us about this idea, and it seems to me much more 
general than CForms. However, I also understand that you may want to use 
CForms as a playground for this experiment. But doing it in the main dev 
line when we are trying to achieve stable state for CForms is IMO dangerous.

So whiteboard/scratchpad seems a good idea. Remember: flowscript started 
there ;-)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message