cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject [RT] Towards a new/another Forms Framework
Date Tue, 01 Apr 2003 14:18:30 GMT
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?

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message