cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: [cforms] New when/choose widgets (was Re: cforms plans, templating engines, etc.)
Date Wed, 10 Nov 2004 17:54:35 GMT
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.

--Tim Larson

View raw message