--- Sylvain Wallez <[EMAIL PROTECTED]> wrote: > Sylvain Wallez wrote: > Continuing to share my (random) thoughts with you on this...
Please do continue. > 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? > - 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). > WDYT? Interesting ideas, please continue :) --Tim Larson __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
