have a look at the W3C XForms CR http://w3.org/markup/forms which describes most of what you're mentioning and is the next generation of web-forms. it's expected to become Final Recommendation in summer.
Joern Turner
Bruno Dumon wrote:
The last few days I've been doing some thinking about form-handling. I've been looking at the current solutions in Cocoon and IMHO there still is room for improvement here and there. BTW, all this has nothing to do with Ivelin's announcements, or with the fact that it's April 1 today. It's been stuff which has been brewing in our heads for quite some time.
I'm not going to write a long proposal here (or at least I'll try not to), but just some notes to make clear in what direction I'm thinking.
It should be possible to create a form just by describing its structure in an XML file (lets call this a "form description"). I don't like the fact that for XMLForm/Struts the user needs to write a bean just to hold the form data. Apparently the struts people are realizing this and have introduced something like 'DynaFormBeans' for this purpose. XMLForm allows to use any DOM document as data-structure, but a DOM document can only hold strings, and not dates or numbers.
(BTW, not using XML, XML validation, and XPath expressions as request parameter names is a conscious choice, so what I'm describing here is quite orthogonal to XMLForm, and leaning more towards FormValidatorAction. XML will of course be used extensively for publishing and configuration.)
A form description would basically list all the "widgets" on the form. Each widget would have an associated type (string, date, long, decimal, ...), a number of validation rules, an id, and other required configuration information depending on the specific widget implementation. A form description would be parsed ones into an object model, lets call this a "FormDefinition". Based on this FormDefinition, a FormInstance can be created, which is a lightweight data-structure that holds the instance-specific data for the form (the submitted values and the validation results). So this would avoid the need to create a bean, since from the user perspective, it would be as if the widgets themselves hold their value.
Of course the kinds of widgets, validation rules, ... should be defined by an interface so that anyone can provide additional implementations.
For the rendering part, each widget-instance should be able to produce an XML representation of itself. Then either a generator or transformer approach can be used to generate or merge-in the data.
The whole approach to think of a form as a set of widgets that can themselves hold their value etc. also returns in JSF (Java Server Faces), so that JSR can also be used for inspiration.
For those cases where the user just wants to make a form above some database-table, EJB or Web-service, we could introduce some mapping-concept that allows to map database fields or EJB properties to widgets on the forms, so that load and store operations can be done without any coding.
Some other things that should be possible with the form-framework: * repeating (iterating) structures (to create tables etc.) * enabling/disabling widgets based on the values of other widgets. * event handling: when user selects an item or changes a value, do an automatic form submit and call an event handler on the server * pose no requirements on the structure of URL's * should be usable together with flowscript, but using flowscript should not be a requirement * ...
All the above are as of yet only ideas, there's no code yet, but once it gets this far I'd like to add it as a block to Cocoon CVS.
Thoughts?
