cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From joern turner <joern.tur...@web.de>
Subject Re: [RT] Towards a new/another Forms Framework
Date Tue, 01 Apr 2003 21:46:29 GMT
hello Bruno,

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?
> 




Mime
View raw message