--- Sylvain Wallez <[EMAIL PROTECTED]> 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
