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.
Since everybody is throwing ideas here in a somehow unordered way, let me throw in mine, considering my experience with our home-grown forms framework that we use since late 2000.
First of all, we use a model to define "entities", which can be either a business object or a form. An entity defined by a set of fields, each field having a type. A field can also be a relation to some other entity (more on this later). This model is more like XMI than like XMLSchema.
On this model, we have different families of mappings : forms mapping, persistence mapping (to store e.g. in a database), javabean mapping (relation to the object model), etc.
The form mapping, and IMO this is where XMLForm has strong weaknesses, defines formats for either datatypes (int, date, etc). or each of the fields. We also make a difference between input and output formats. A date for example, can be displayed as "Wednesday 2 april 2003" but input as "04-2-2003" on the same screen. Formats can also be i18n-ized, meaning the previous example on a french browser will be displayed as "Mercredi 3 avril 2003" and input as "2/4/2003".
Since fields can also be defined as relation to other entities, we can use this information to automatically populate pop-menus and lists. This is a little bit like the "beaff.enumeration" in Bertrand's proposal.
Once we have an entity model an some associated formats, we can feed a view with it. The view contains some "widgets" related to either a datatype or a particular field. This allows for example to have any input associated to a date field automatically converted to an input with a fancy calendar popup and some client-side syntactic validation;
When the form is submitted, the server-side validation framework parses each input with the format defined in the mapping, and feeds the data model, reporting any violation.
Now back to the discussion.
In the above, the important features that are currently missing in XMLForm are mainly the ability to define the input/outpout format for non-trivial datatypes such as dates.
Also, we must be able to define a forms model through a configuration file, avoiding the need to write Java code for simple cases. DynaBeans are IMO a good solution for this, and are becoming the de-facto standard for dynamically typed objects at least in the Apache-Java world.
Next, I would like Cocoon's form solution to be based on existing components. Form validation is a sooo common problem that we should avoid as far as possible to reinvent the wheel and concentrate on the Cocoon-specific part of form handling, which IMO is mainly in the view area : form population, widgets, etc.
A good candidate seems to be commons-validator : a lot of work is going on there, and joining forces will lead to a more featureful package than if we do our own. Also, as I stated in a previous post, this promotes cross-project collaboration and will ease the migration of users between the various Apache frameworks. And this can only be good for Cocoon.
Ah, and special thanks to Stephen Burns for his version of XMLForm based on commons-validator. This definitely has go in our code base.
Thoughts ?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
