cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [cforms] New when/choose widgets (was Re: cforms plans, templating engines, etc.)
Date Thu, 11 Nov 2004 13:17:11 GMT
Hey, Marc comes back :-)


Marc Portier wrote:

>
> Sylvain Wallez wrote:
>
>> Tim Larson wrote:
>>

<snip/>

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


I totally agree: we need some system-level expression evaluation 
facility in Cocoon. But that's another hot subject lately, which has not 
yet reached consensus. Once progress will be made regarding expression 
languages, we may reconsider it for CForms _if we feel it is needed_ (up 
to now, with rather complex use cases, I never had this need).

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


"choice" sounds good, actually, and "select" is also a verb.

<snip/>

>> 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


Sure, but that's what we have today with the union/case widget and 
that's why we need to fix it :-)

<snip/>

>> 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.
>
>
> I like it


Great!

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