cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@codeconsult.ch>
Subject Re: [RT] Towards a new/another Forms Framework
Date Tue, 01 Apr 2003 14:50:45 GMT
Le Mardi, 1 avr 2003, à 16:18 Europe/Zurich, Bruno Dumon a écrit :

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

Mime
View raw message