cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject [cforms] New when/choose widgets (was Re: cforms plans, templating engines, etc.)
Date Sun, 07 Nov 2004 20:29:56 GMT
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.

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.

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.

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.

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.

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.

Thoughts?

Sylvain

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



Mime
View raw message