On Sun, Nov 07, 2004 at 09:29:56PM +0100, Sylvain Wallez wrote: > Tim Larson wrote: > >On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote: > > > >>Ok. Does this mean choose/when will replace union/case? Also, the wiki > >>[1] shows several alternatives for choose/when, and unless I missed > >>something we have not decided which approach to use. > > > >Yes, choose/when is intended to replace union/case (following > >with any deprecation pattern that is needed). There are two > >alternatives, with the intention to have *both*, to service > >different usecases. > > Preliminary notice: don't get me wrong with all these questions and > remarks. I'm shaking the concept so that it solidifies and we all agree > on how it should behave before starting to write down some code.
Thanks for providing feedback :) > So, why do we need *both* versions? Isn't it FS? Can you give some > examples that justify this need? Up to now, I personally never had the > need for evaluated conditions. I sometimes would like to use types other > than String, and that can easily be done by associating adding a > convertor that defines how values for the different cases are to be > converted to typed values. Your converter idea for handling other datatypes sounds good. I personally only need the simple switch version that references a widget (via a path passed to lookupWidget()) for the switch value and selects the case which has the id matching the value. Others requested the expression-on-every-case version, so they would have to supply usecases for that version. > Furthermore, what expression language will be used? This leads us back > to the discussion about expressions in JXTG, and the necessary > unification of expression evaluation within Cocoon as a whole. I'm also > not a fan of xReporter's expression language which is really specific to > CForms. I got stuck on this point also. Perhaps someone with a usecase for the e-o-e-case version could comment? > Also, there are some points I'd like us to to formalize. > > 1/ The wiki uses "choice" and "case" for the definition and "choose" and > "when" for the template. IMO, this is confusing and we should have the > same wording in the definition and in the template. I would use the same names in template, model, and binding. "choose/when" seemed to me to be the closest to consensus. Anyone have a different opinion? > 1/ Is it a container? Looking at the wiki, the "valued expression > selects case" version has no id. Also, are each fd:case also containers? > My opinion is that fd:when should be a container, but not fd:case. This > is enforced by the reuse of widgets between cases. Choose and when would both be *implemented* as containers, but they would not affect the paths/namespaces of the widgets they "contain". Think of it as a control structure rather than as a real container "widget". Also the id on the "choose" should be optional. For example, this would allow the model to choose between two widgets with the same id but with different datatypes without having to modify the corresponding template to recognize that a choice is even being made. In this example there is no need for "choose" to have an id, because the choice does not need to be referenced. For a "choose" that picks between different sets of widgets, or whenever you want the template or binding to be able to react to the selected choice, then the "choose" control structure will need an id. > 2/ Widgets for a case: do we allow inline widgets to be defined in a > fd:case, or only have references with fd:ref? Allowing both may cause > some naming problems (this is also related to the previous question > about containment), as an inline widget's name may conflict with a > widget defined in fd:when. Similarily, if fd:case is not a container, > widgets having the same name in different fd:cases will conflict. Allow widget definitions in the "choose" for cherry-picking in the "when"'s (refered to as fd:case's above,) and also allow widget definitions in the "when"'s. This allows for the type of example I described above. WDYT? --Tim Larson
