cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject CForms: merge of 2.1 and 2.2 branches
Date Thu, 04 Nov 2004 10:33:53 GMT
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 

- 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message