cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Towards a new/another Forms Framework
Date Wed, 02 Apr 2003 13:25:40 GMT
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.

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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message