Done, I've committed the two-way merge of CForms.
However, there are some items that I have not synchronized:
- form.fireEvents in Form.js: why is it needed? The form object buffers events only during the readFromRequest phase, and otherwise always broadcasts them immediately
- field.removeSelectionList: there's a big problem behind it, as it calls definition.setSelectionList(null). It's important that widget definitions be *immutable* as they a reused for different instances of a form.
- getProcessMyRequests: we have to see how this relates to widget states.
- ft:choose: we've talked about it already, and I removed it until we know more about Tim's experiments.
A few questions, also:
- no generation of fi:union and fi:struct: does it have to be removed at template execution level, or should it be filtered by the XSLs? In other words, can the stylesheets do something useful with it? If we consider that fi:struct can be renamed to fi:group, we obtain at the form definition level the "instance-only" fi:group we have today to build tabbed forms and automatic layout.
- what's the difference between "nestedHandler" and "skipHandler"?
- <ft:widget id=""> now considers not only child widgets, but also paths using lookupWidget(). That's a good idea, but now the "id" is no more an identifier in the strict meaning of the word. Should we rename it to <ft:widget ref=""> (with the additional meaning that it _references_ a widget in the form definition), or leave it as is?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
