cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: wd:choice semantics (was Re: Rename "union" to "select"?)
Date Mon, 05 Jan 2004 15:03:32 GMT
Tim Larson wrote:

>--- Sylvain Wallez <sylvain@apache.org> wrote:
>  
>
>>Sylvain Wallez wrote:
>>Continuing to share my (random) thoughts with you on this...
>>    
>>
>
>Please do continue.
>  
>

No need to ask ;-)

>>There are two problems we will quickly face with the current way 
>>"choices" identifies the case:
>>- what's the format (or convertor) used for "case" values?
>>- how can I express more complicated cases, e.g as comparisons?
>>
>>The answer to both cases is to separate the case value from a widget 
>>value and turn it into a simple expression.
>>    
>>
>
><snip examples/>
>
>  
>
>>Several things to notice here:
>>- the "expected-temp" value considered uses the unit used 
>>application-wise (here deg-Celsius) watever the input unit for the user.
>>    
>>
>
>Do you have thoughts on dealing with unit localization, i.e. some users
>are asked to enter values in deg-C while others are asked to enter values
>in deg-F, but we want to use the same expressions to evaluate both?
>Oops, sorry.  Probably just use localized converters in readFromRequest
>and then have no issues here?
>  
>

That's exactly the point: there's no issue, as the expressions use 
widget.getValue and therefore use the exact same representation (and 
unit in the case of temperature) as other places of the application.

I chose the "expected-temp" example on purpose, as it can have a wide 
range of input/display formats depending on both the language (i.e. 
floating point format) and country (i.e. deg-C or deg-F), but the 
widget's value used in the expression will always be a Float in a single 
unit (here, I considered deg-C).

>>- the <wd:otherwise> clause.
>>    
>>
>
>Nice.
>
>  
>
>>The test condition above only involves the "expected-temp" value, but we 
>>could also combine it with "expected-weather" to allow for the selection 
>>of boots and t-shirts for tropical rains and regular shoes and anoraks 
>>in dry and cold areas.
>>    
>>
>
>What should we do if more than one expression tests true?
> (1) Say, "Don't do that!" to the programmer
> (2) First match wins
> (3) Allow all the widgets from cases where the expressions test true?
>I lean toward (2), but might be able to be convinced of use cases for (3).
>  
>

I share your opinion: (2) is consistent with XSL, and (3) may reduce 
verbosity but can also be confusing.

Sylvain

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



Mime
View raw message