cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [cforms] New when/choose widgets (was Re: cforms plans, templating engines, etc.)
Date Thu, 11 Nov 2004 12:42:57 GMT


Sylvain Wallez wrote:
> Tim Larson wrote:
> 
>> 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:
>>>>

<snip />

>>> 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.
>>  
>>
> 
> Good. So people, if you need expression on every case, please speak up!
> 

I remember suggesting that, but it's not driven from a concrete use 
case, just a personal feeling of simplicity (let's not call it FS he :-))

just the general observation that a construct of the kind

switch (variable_to_check)
   case value_1:
   case value_2:
   case value_3:
   default:

really is a special (simpler) case of some

if (test1)
else if (test2)
else if (test3)
else

rather then the reverse, but that is a personal feeling: if you really 
have more then one variable driving the decissions than the switch 
construct forces you to invent a formula producing some 'virtual' 
switch-variable, if not then the if-else-if is probably just a bit more 
typing

also, observing that deep down the implementation will be mapped on an 
if-else-if anyway it might be just doable

so far for the context, I understand you guys push for a decission so:
- I dont' think the usability would be limiting that much either way 
(one can always find use cases that will argument in favour of one or 
the other, so *shrug*)
- as agreed on the hackathon: going forward towards cforms-stable is far 
more important then nth degree of slickness in feature-completeness


> Also, if that need is because the case values are computed and not only 

that's indeed the only point

> a single widget's values, that can be modelled by a <fd:output> widget. 

so we have a workaround that can be documented

> And the initialize() stuff Tim added will allow to finish the on-create 
> event handler I started to implement, thus allowing computed widgets to 
> register themselves as change-listeners on widgets their value depends on.
> 

cool

>>> 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?
>>  
>>
> 
> :-)
> 

I agree: the issue of which expression language to take is another 
(practical) counter-argument

(although making the observation that something like this starts 
limiting our design-freedom really suggests that we should do something 
towards hiding all those expr-script-languages floating around in cocoon 
behind some generic interface, no?)

>>> 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?
>>  
>>
> 
> "choose" is a verb whereas "widget", "repeater", "field" are nouns. 
> Using a noun therefore seems more consistent to me and that would be 
> therefore "choice". But I've been also thinking lately about "select" or 
> "variant". Naming is a difficult but important subject, as it conveys 
> the underlying semantics.
> 

I remember also the suggestion to let it be influenced by the 
'normal-live-nomenclature' of the typical end-user....

current naming seems to have a C-programming heritage,

'choice' was suggested for it's schema/dtd ring to it

'select' would probably yield the wrong association in HTML infected heads?

'variant' doesn't say a thing to me, but that might be a plus :-)


>>> 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.
>>  
>>
> 
> IMO, the choice widget is "something", i.e. a structural unit like other 
> widgets, whereas the various alternatives are more variants of what's in 
> that thing. That means that choice would have an id and therefore affect 
> the path, but not the cases which define what widgets are children of 
> the choice depending on the case value.
> 
> Consider the following example (datatypes ommited for brevety) where we 
> define the connection setting to a datasource (for example a CVS server):
> 
> <fd:choice id="datasource" case="datasource-type">
>  <fd:widgets>
>    <fd:field id="server"/>
>    <fd:field id="path"/>
>    <fd:field id="login"/>
>    <fd:field id="password"/>
>  <fd:widgets>
>  <fd:when case="local">
>    <fd:widget ref="path"/>
>  </fd:when>
>  <fd:when case="remote">
>    <fd:widget ref="server"/>
>    <fd:widget ref="path"/>
>    <fd:widget ref="login"/>
>    <fd:widget ref="password"/>
>  </fd:when>
> <fd:choice>
> 
> The "datasource" is an entity and threfore should appear in the path, 
> whereas "local" and "remote" are just test values. So we have 
> "datasource/path" (always) and "datasource/login", "datasource/server" 
> etc (when case is "remote").
> 

I agree, surely it would feel awkward to have 'remote' (a value!) in the 
name-path


>> 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.
>>
> 
> Sorry, but I find having the same id for different widgets depending on 
> the choice condition very confusing. IMO, an id should designate one 
> thing only, without ambiguity.
> 

+1 being infected by java and xml I favour (verbose) explicity over 
terseness (and magic)

> The choice condition should define _which_ widgets (and therefore ids) 
> are available, not _how_ these widgets are defined. Also, it's very 
> likely that a choice in the definition also leads to a choice in the 
> view and in the binding.
> 
>> 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.
>>  
>>
> 
> And if it's got an id, it's no more a control structure, but a widget, 
> hence the naming with a noun rather than a verb as outlined above.
> 
>>> 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.
>>  
>>
> 
> ... which I found confusing :-)
> 

same here,

feels a bit like we're mixin' in the concern to reduce typing?

IMHO that aspect should be handled by the registry and new/class stuff?


> IMO, inline widget definitions in the "when" can be considered as 
> shortcuts for defining a widget in the choice and then referencing it 
> when that widget only applies to one particular case, i.e. :
> 
> <fd:choice id="foo">
>  <fd:when case="bar">
>    <fd:field id="baz"/>
>  </fd:when>
> </fd:choice>
> 
> Should be strictly equivalent to writing :
> 
> <fd:choice id="foo">
>  <fd:widgets>
>    <fd:field id="baz"/>
>  </fd:widgets>
>  <fd:when case="bar">
>    <fd:widget ref="baz"/>
>  </fd:when>
> </fd:choice>
> 
> That also means that child ids must be unique throughout the various cases.
> 
> WDYT?
> 

I like it

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message