cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [CForms] union case as relative path
Date Thu, 17 Jun 2004 07:34:16 GMT
Tim Larson wrote:

>On Wed, Jun 16, 2004 at 04:49:44PM -0600, Johnston, Jason wrote:
>  
>
>>Thank you for your reply, Tim...
>>    
>>
>
>We do not have code ownership here, but I still feel some healthy
>responsibility to help support code that I helped add, especially since
>not very many other developers seem to have figured out this piece of
>code yet.
>  
>

Having started to use it a few weeks ago, I'm currently starting to look 
at it ;-)

>>>Working from memory alone, I only see three issues:
>>>* Where do you want the lookup to be relative to?  Probably relative to
>>>  the parent (like I think you are suggesting) would make the most
>>>  sense.
>>>      
>>>
>>I agree with you, relative to the parent seems the most logical and is
>>consistent with the current behavior.
>>    
>>
>
>Good, I think we can keep backwards compatibility then, for whatever it
>is worth...
>
>  
>
>>>* There may be sequence of execution issues if the widget you reference
>>>  is defined below (further down the file) than the union itself, as in
>>>  the case-determining widget's request parameter may not have been
>>>  processed in time to contribute to the union's case selection process.
>>>  You will need to test this and either document the limitation or
>>>  design some way for this dependecy to reorder the request parameter
>>>  processing to eliminate the problem.
>>>      
>>>
>>How is this issue currently resolved?  What happens if a union is
>>defined and then its case-determining widget is defined directly after
>>it?  It seems the dependency you describe would exist regardless of if
>>the widget lookup uses getChild() or lookupWidget().
>>    
>>
>
>The current code does have this limitation.  I just mentioned it so
>everyone would be aware of it, and in case anyone wanted to fix it :)
>  
>

Are you sure this limitation exists? In union.readFromRequest(), there's 
a explicit call readFromRequest on the case widget to ensure it properly 
got a value.

>>>* The union widget is being redesigned and will be replaced by "choice"
>>>  described here: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad
>>>  The good news is we can probably reuse the good solutions you come up
>>>  with for the union widget when we implement "choice/case".
>>>      
>>>
>>That's an interesting read and I'm looking forward very much to the new
>>choice/case paradigm.  The current union is useful but becomes very
>>unwieldy and limiting if complex selection logic is needed.
>>    
>>
>
>Agreed.  The complexity, inflexibility and poor choice of name triggered
>the redesign.  I still wonder if in the new choice/case design we need
>to be able to split apart control of which widgets' request parameters
>are processed versus which widgets get validated.  Any thoughts?
>  
>

Sorry, got lost here: can you elaborate?

>>How actively is the new choice/case widget being developed?  Will it
>>replace union altogether or supplement it?  If switching union to use
>>lookupWidget() as I originally described turns out to function properly
>>would a patch be accepted in the official tree?  I'm new to the Cocoon
>>community's development process so please forgive my ignorance.
>>    
>>
>
>Marc and I were trying to develop it, but we both ran out of time.
>Anyone is welcome to code it.  I would also welcome incremental
>improvements like lookupWidget to the union widget in CForms, and don't
>_think_ others would object either.
>  
>

+1. And count me in to work on the new choice/case.

>Changes to the copy in Woody (the old frozen version of CForms, only
>left in to help with migration) would be a harder sell, probably
>requiring a vote, and might get voted down because Woody is frozen.
>  
>

Rather than backporting to Woody, I really think people should migrate 
to CForms. The transition isn't that hard and brings many benefits. 
Also, I recently made some changes to ensure that the CVS version also 
works with the 2.1.5 release (and problably some of the previous ones also).

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