22StabilizeCocoonForms

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)
[DONE] 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)
[DONE] implement widget.getDefinition() (give access to form definition)
rename showForm() 'bizData' parameter to 'viewData' (a la v3): http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111951875814550&w=2

[DONE] ignore the "action-command" attribute which is currently useless except for repeater-actions and row-actions
[DONE] implement widget states
[DONE] review widget states (maybe an output state is necessary)

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
restructure resources directory (group XSLs and put them into their own directories)
second wizard example - shows how one form that is used in several templates can be controlled by Flowscript
Review multi-form-per-page - does it work? - provide a sample
Update the tour block samples to be in sync with these changes

Enabled modify form define through api
- I have a usecase for this too (RP): Depending on the content of a form, a dynamic number of actions can be triggered. The possible actions are stored in a database and have to be read out at form creation time and action-widgets have to be set dynamically.
Remove everything that has been deprecated (union/struct, old validators, ...)