cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: Rename "union" to "select"?
Date Mon, 05 Jan 2004 14:20:33 GMT
--- Sylvain Wallez <> wrote:
> Marc Portier wrote:
> I like "choice" which is a noun better than "select" which is a verb.

I assume you mean better as in more declarative than imperative?
Sounds good.

> Also, it seems to me that "class", "struct" and "new" are variations 
> around the concept of widget groups. We could then have:
> - "group-template" for "class"
> - "group-instance" for "new"
> - "group" for "struct"
> How does it sound?

Sounds like a correct analysis.  The group-* names may cause some
misunderstanding however, because of the different semantics of
"struct" versus "new".  "struct" exists to wrap a set of widgets
in a namespace, while "new" does not providing a wrapping namespace.
The original idea was to allow several uses of "new" to include
several classes into a "union", with each class providing multiple
additional choices (cases) for the union.  Should we change "new"
to have it provide a wrapping namespace?  Then we would have to
support union cases with names like "some-namespace.some-widgetname".
How would this interact with your union proposal below?

I like the proposed names if we can solve this cleanly, and deal with
the first two being so long...

> Note also that we can make a direct parallel between "wd:group" (former 
> "struct") and the instance-only "wi:group" wigets I introduced in 
> woody-page-styling.xsl.

I am interested.  Would you explain what you are thinking in more detail?

> Finally, something that bothers me in "choice" (currently "union") is 
> that the various cases only appear in the template, but not in the 
> definition. It would be better IMO to define the choices in the form 
> definition to ensure there's no accidental mixing in the template.

There currently is no danger of mixing.  Each direct child widget of a
union is a "case" for that union.  If you need a case to include more than
one widget, then you are forced to wrap the set of widgets with a container
widget (such as "struct"), and then the *container* acts as the union case.

> Or maybe was it done on purpose to allow a single widget to be present 
> in several cases?

As explained above this was not the idea, but it is an interesting

> If true, then we can have a single namespace for child 
> widgets as of now, and have additional "case" statements in the 
> definition identifying which widgets can appear in which case.
> We could then have:
> <wd:choice id="schedule" case-widget="travel-type">
>   <wd:label>Travel schedule</wd:label>
>   <wd:widgets>
>     <wd:field id="departure-date">...</wd:field>
>     <wd:field id="return-date">...</wd:field>
>   </wd:widgets>
>   <wd:when case="one-way">
>     <wd:use-widget id="departure-date"/>
>   </wd:when>
>   <wd:when case="two-way">
>     <wd:use-widget id="departure-date"/>
>     <wd:use-widget id="return-date"/>
>   </wd:when>
> </wd:choice>
> We may also have a "permissive mode" when there's no <wd:when> statement 
> that would allow any widget for any case.
> Ah, and another question: why is the case-selection widget a sibling of 
> the "choice" widget? Shouldn't it be a child widget? This would allow an 
> stronger semantic grouping. But I'm not sure if this is good...

Originally, the "union" widget held the case value itself, but was
changed to reference a separate widget to determine the case value.
The idea was to allow multiple unions (and other dependent widgets, when
dependencies get implemented) to feed from the same case value.  I have
considered allowing the union case to be specified as expression that could
reference multiple widgets while calculating its value.  I opted instead
to focus on adding support for dependent widgets (widgets whose values are
automatically calculated based on other widgets values) and then letting
the union reference one of these dependent widgets to get its case value.

--Tim Larson

Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003

View raw message