cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject [RT] BEans And Forms Framework (BEAFF)
Date Thu, 21 Nov 2002 09:04:13 GMT
--- INTRO ---
I think Torsten Curdt's GetTogether presentation [1] of the various ways of 
writing webapps with Cocoon makes it clear that something better is needed to 
write CRUD [2] applications with Cocoon.

No-one wants to have to modify three configuration files in three different 
languages every time a field is added to or removed from a form.

Here's my suggestion for a simple framework for data entry and forms-to-beans 
mapping. I think using this together with flowscript, Hibernate [3] or OJB 
[4] for storage and XSLT for presentation would be all that is needed to 
build CRUD webapps fairly easily and in a very scalable way.

These describe how I'd like to build webapps. BEAFF (or elements of it) would 
certainly be usable in other contexts but initial development should focus on 
a simple environment.

-Cocoon is used to build CRUD [2] applications. 

-Business logic is implemented in backend java classes.

-Java Beans (not EJB - normal java classes with Beans name conventions) are 
used to hold data and interface with the backend.

-Flowscript is used for flow control and interface between frontend (forms) 
and backend (beans). 

-Except for very simple stuff (required fields etc.), data validation is done 
by the java backend. I don't want junior programmers working on flow changes 
or page layout to risk breaking the business level validations, and backend 
code and validations usually outlives the front-end and flow stuff, so it 
makes sense for me to keep them together.

--- BEAFF - THE PLAN ---
-Use an XML-based data dictionary (DD) for fields, datatypes and beans 
definitions. See example below.

-DD can use enumerated types obtained in XML from Cocoon pipelines.

-A Transformer creates form fields by replacing placeholder elements in pages 
by appropriate labels (i18n-able) and data entry elements (HTML <input> and 
the like) computed from the DD. Custom "field builders" can optionally be 

-A Transformer populates forms values by using DD definitions to get data 
from Beans. Custom mapping classes can optionally be used.

-BEAFF classes are used (by the flowscript layer) to convert suitable HTTP 
request parameters into the appropriate java data types based on DD mappings. 
This includes basic validity checks (string-to-integer etc.). Custom mapping 
classes can optionally be used.

-BEAFF classes are used by the flowscript layer to move this converted data 
into the beans, form-by-form, without having to explicitely write copying 
code for each field. This uses java reflection mechanisms to be fully dynamic.

-Beans classes are generated at compile-time by an ant task based on DD 
information. Generated Beans include hook functions to allow data validation 
and database interactions to happen in derived classes written by the 
application programmer.

--- EXAMPLE DD ---
I don't know XForms and schema stuff very well, maybe these could be used 
instead of a custom DD format. The aim here is to describe what must be in 
the DD, not necessarily to be an implementation format.

<data-dictionary name="cd-library" java-package="myapp.beans">
  <!-- custom data types -->

  <!-- reusable field definitions -->
    <field-type name="artist" data-type="myapps.beans.Artist"/>

  <!-- application data model -->
    <bean name="MusicCd">
      <field data-type="java.lang.String" name="title" required="true"/>
      <field data-type="musical-style" name="style"/>
      <field data-type="artist" name="artist" required="true"/>

    <bean name="Artist">
      <field data-type="java.lang.String" name="name" required="true"/>


I think this is sufficient to generate fields in forms, map beans values to 
forms and map HTTP request parameters to beans. 

Of course more DD options will be needed for custom formatters/parsers but 
for a start the above should be sufficient.

--- CODA ---
I cannot imagine this doesn't exist yet, but I couldn't find a library that 
does all that we need here. Suggestions?

The power of BEAFF lies in the leverage given by the DD - changing DD info 
updates all the required pieces of the application front-end (and backend 
interface) with minimal effort.

Other than that: fire away... ;-)

 Bertrand Delacrétaz (,

[2] CRUD=Create Retrieve Update Delete

To unsubscribe, e-mail:
For additional commands, email:

View raw message