...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...
Maybe going all the way down to a kind of "data dictionary" that describes the data model and tools to work with it would be even better?
A while ago I suggested something along these lines (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103786946103965&w=2), there was little response at the time and I didn't follow with concrete code but you might find it useful.
I think you need three mappings to write a complete web application, and these should ideally all derive from the same definitions (what I call the data dictionary). Might not be doable right away, but designing the dictionary for these uses could be very useful later on (need to check the YAGNImeter though):
-mapping from data to XML forms
-mapping from request attributes to data (type conversions, key lookups, etc.)
-bidirectional mapping from data to storage (database or XML)
Not to mention other things that can also be stored in a data dictionary, like internationalized fields names, links to help pages, hints for acccessiblity, etc. Some of this belongs to forms, but a lot of it is broader in range than forms, hence the idea of central repository for this information, not limited to forms.
Of course form definitions are needed at some point, but with a system based on a data dictionary they could be very simple, just listing which fields go in which form. Also useful when a field is used in several forms.
...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.
Would be cool but won't you need beans anyway for storage, java-based validations and the like?
I'm not sure if script-based validations are good enough, I prefer to write the heavy-duty validation stuff in code that is independent from the web application framework (but that's a personal preference).
....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.
That's where I think a data dictionary can help: forms AND database fields can be derived from it, it contains more info than just the forms definitions.
<snip-other-good-ideas/>
I don't know the existing XMLForm stuff in as much detail as I'd like (haven't actually used it yet), so some of my comments might be irrelevant, but hopefully this helps!
-Bertrand
