cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [RT] Towards a new/another Forms Framework
Date Tue, 01 Apr 2003 14:44:13 GMT
Very interesting - do you envision it covering client/server side validation?


At 09:18 AM 4/1/2003, you 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.
>Bruno Dumon                   
>Outerthought - Open Source, Java & XML Competence Support Center

View raw message