Hi all,
Here's the result of the discussion at the GT about the work needed for CForms to reach stable state. Thanks to Pier for being the secretary. He did it so well ;-P
Flowscript integration:
- don't use JS wrapping classes for widgets: they introduce yet-another-API which is sometimes confusing.
- update the widgets' java public API so that it's more "Rhino-friendly" (check JavaBean conformance and add accessors where needed)
- implement an equivalent to the bookmark feature of V2, by a function property of the form that gets called at each request roundtrip
- add helper methods to the Form class to create event listeners from JS functions
- restrict the "cocoon" object that's available in the event handlers so that it does not provide response-related methods (sendPage etc)
Java code:
- ignore the "action-command" attribute which is currently useless except for repeater-actions and row-actions
- implement widget states (a patch has been provided for this which I will take care of)
Misc:
- write a form definition schema so that definitions can be optionally validated.
- flatten the CForm-related component in cocoon.xconf. This will ease the transition to a non-Avalon container
There was also a discussion also after my presentation on union & class about renaming these widgets to something more meaningful to people having no C knowledge. The renaming we came up to is as follows:
- <fd:union> --> <fd:choose>
- <fd:case> --> <fd:when>
- <fd:struct> --> <fd:group>
- <fd:class> --> <fd:macro>
- <fd:new id=""> --> <fd:expand macro="">
The renaming of class/new to macro/expand is mandated by the fact that a <fd:new> inlines the contents of the class definition without an enclosing container.
Sylvain
What's the status of the binding framework? Found these mails from march: http://marc.theaimsgroup.com/?t=108059916300004&r=1&w=2
At least, on-delete-bean is missing, isn't it?
-- Reinhard
