cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: [RT] Towards a new/another Forms Framework
Date Wed, 02 Apr 2003 21:26:29 GMT
On Wed, 2003-04-02 at 15:25, Sylvain Wallez wrote:
[...]
> 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.

Hmm, I think these entities actually have a lot in common with was I
thinking of for my "form description", except that it's not focussed on
forms only.

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

I think XMLForm just follows the Struts-design here. In struts, you are
supposed to make all form bean properties that correspond to HTML
textboxes of type String. This is because the purpose of the form bean
is to hold the data entered in the form -- which may be invalid dates or
numbers.

In Struts, it is then the purpose of the validator to check that the
dates or numbers are indeed valid dates or numbers (but it leaves them
as strings in the form bean).

Once everything's valid, some other (user-written) code is supposed to
read the values from the form bean, convert them to actual date or
number objects, and then apply them to the business bean.

(I got the above information from reading some messages by Craig
McClanahan on struts-dev, so it's pretty authoritive)

A problem in the above scenario is that both the validator and the
conversion-code need to be aware of the user's locale and the formatting
pattern used. And the same when you fill up a form bean with data from a
business bean. I don't know how or if struts helps here.

That's why in my form ideas I would let a field hold both the string
value and the converted object, and let conversion happen as part of the
validation. If "other code" then reads the field's value, it doesn't
need to do any conversion anymore.

Just wondering: in your form-framework, if conversion of the
user-entered text to e.g. a date fails, where do you store the
user-entered text for re-display on the form? Maybe as part of the
validation error?

> 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".

Agreed on the input and output formats -- we have the same in xReporter.

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

What I've mostly learned from your explanation is that what I called the
"form description" is in your framework separated out in entity
definitions and a form mapping. (I'm undecided yet on wheter I like this
better -- need to sleep a night over it)

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

I completely agree on the reuse and joining forces, as long as it fits
with what we're looking for.

I'm also wondering how struts (and related to this, dynabeans and
commons-validator) will evolve in the future, since from what I
understood from struts-dev, the long-term plan is to migrate to JSF,
which has its own validation system, and doesn't have the concept of
form beans.

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


Mime
View raw message