Reinhard Poetz wrote:
Sylvain Wallez wrote:
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?
Maybe :-) (I'll have to look at this in deeper detail)
About the repeater binding, I had an simple idea that could tremendously simplify the binding job: a repeater could have a row creation counter, each row holding it's own counter value.
Upon load, rows would be numbered e.g. 1, 2, 3, 4. On save, if we find e.g. rows 4, 1, 5, 13, we can determine that rows 4&1 were moved, rows 2&3 deleted and rows 5&13 are new. That may avoid that complicated (and difficult to understand) unique-id stuff that is currently needed in the repeater binding.
Another option to ease repeater binding could be to attach the loaded data as attributes in the widget row, thus giving instant access to that data at save time. And if some rows don't have that attribute, we know that these are new ones.
WDYT?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
