cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: choose/when: container or control-structure?
Date Sun, 21 Nov 2004 09:24:29 GMT
Tim Larson wrote:

>The use of a choose in the form model should be invisible
>to the form template and form binding, just like use of a
>choose in the form template is invisible to the form model.

I don't agree with this: a choose defines a set of widgets that will be 
present or not in the form depending on some test. The fact that it is a 
*set* of widgets implicitely makes the choose a container.

>Only structural differences between choices should force
>the parallel use of a choose in the template and binding.

Sorry, but what's the purpose of a choose if it's not providing 
structural differences depending on the case test?

>A choose may be used in the form model without causing
>structural changes.  For example, identical sets of widgets
>may be referenced into two or more when branches, with the
>sole pupose of the choose control structure being to trigger
>event handlers to toggle the widgets' states.  In this case
>it would be an unnecessary mixing of concerns to force the
>knowledge of the form model's choose onto the form template.

Sorry (again), I don't follow you here: using a choose to implement 
event handlers? Why should we use a choose for that? IMO, the mixing of 
concern is in using a choose for something else than structural 
variations :-)

>This leads to choose not being treated as a container, but
>rather as a control structure.  The id of the choose should
>not be injected in the id's of the widgets which it controls
>because this would force the template and binding to know
>about its presence even when they do not need to, needlessly
>increasing the coupling between the layers.

Well, choose being IMO useful only for structural variations, its id 
must appear in the widget path!

What must not be present in the path, however, is the id of the chosen 
variant, which currently forces us to use an extra <ft:struct> in the 

>PS: There is a list of other issues to resolve about the
>choose widget (naming, optional id, referencing widget defs
>versus inlining widget defs in the when clauses, different
>widgets defs in each when clause with matching id's, etc.),
>but let's addres them one at a time to reduce confusion.
>After this first issue is resolved I will start separate
>threads to discuss the other issues.

That's a good way to handle all the different points, especially 
considering the diverging opinions on this first one :-)


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message