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 template.
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
