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 }
