This is a for-discussion-and-revision document, not a statement of fact. So, please jump in, discuss, revise, and thoroughly refactor

The page layout is intentionally rough to encourage perfectionists to contribute

First let's express the needs from the standpoint of various people:

Form Definition Designer (i.e. the one on the 'cubist' spot, looking at it from all viewpoints, needing to supporting hooks to enable the needs of the others.) He does seem to have an own agenda for that:

definition of the HTTP-interface

names and 'styles' of request-parameters supported on this form

easy management through definition reuse and definition repositories

specifying datatyping and validation

local event-handling (with no effects outside the form scope)

providing hooks to the processing (actions, submit with or without validation,...)

Can all values and attributes be referenced and manipulated from all environments where appropriate?

(e.g. java, js, event handlers, bindings, templates)?

Does the transformer have any compelling use-cases left where it is better than the JXGenerator approach?

If desired, can the JXGenerator be extended to handle id/extends/defines and choice? (probably yes)

Now let's toss out some more ideas to refine:

Other Random Thoughts:

BooleanField

Even if we use a custom class to implement BooleanField's, why do we expose this in the XML definitions? (mpo: the reason is that the request-parameters are different, I like the fact that the form-definition editor is in control of the HTTP-interface of his form, after all cforms can be used without flow but even without the forms generator or transformer. Controlling this technical interface is essential IMHO)

We need support for both Booleans (true/false) and "Trileans" (true/false/null).

Struct

Rename "Struct" to "Composite", "Group", or whatever make the most sense to us.

Convertor

Rename to "Converter"? (Check relative hit-counts on google)

Repeater

Use an established terms for this concept: "Array", "Grid", "List", ...

Do we need more direct support for other variants, such as sparse arrays and multi-dimensional arrays?

MultiValueField versus Repeater

We have single value widgets (Field, BooleanField, Output)

We have multi-value widgets (MultiValueField, Repeater)

And the progression is something like this:

Field->MultiValueField->Repeater

What benefits does MultiValueField give us over Repeater?

Four less lines to type each time. (ouch)

One less widget id to create.

What do we pay for this?

One more concept to learn/teach/maintain in the model, binding, and template. (main point)

Only works like a list of Field-type widgets, not BooleanField, Repeater, etc.

No support in the binding for identity and Repeater's set of binding strategies.

What is missing to drop MultiValueField in favor of using Repeater?

(Not suggesting to do this drop, just looking at the possibility to see if there are any benefits.)

Design Repeater selection-list to at least match features with the MultiValueField selection list.

Should we use a common XML syntax, while backing it by the more efficient MultiValueField-like class?

An alternate idea would be to make the Repeater semantics more integrated:

Eliminate Repeater and MultiValueField and instead allow any type of widget to be "repeated".

For example: (*Not* suggesting syntax, just *very rough* semantics to get ideas flowing)

*MultiValueField: <fd:field id="some-id" multi="true"/>

*Repeater: <fd:composite id="some-id" multi="true"/>

mpo: on this integrated syntax I somewhat have the same reflex as on the 'booleanfield' since multivalue and repeater lead to different request-parameter handling (x=1&x=2 versus x.1.a=i&x.2.a=j) I would welcome explicit split syntax in the definition file. But the essence of the above still holds: 'allowing repetitive values' seems to be an aspect of widgets that we could abstract out. See also discussion here: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108209653422163&w=2