Return-Path: 
 <cocoon-dev-return-33111-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 9600 invoked by uid 500); 21 Nov 2002 09:52:33 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 9553 invoked from network); 21 Nov 2002 09:52:32 -0000
Message-ID: <3DDCADB7.1010403@anyware-tech.com>
Date: Thu, 21 Nov 2002 10:56:07 +0100
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.1) Gecko/20020826
X-Accept-Language: fr, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] BEans And Forms Framework (BEAFF)
References: <20021121090414.4B45523CD8@dj.codeconsult.ch>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Bertrand,

I have to read all this carefully, but a quick reading reveals a very 
interesting idea that I would like to point out to be sure people don't 
miss it : using Cocoon pipelines to "expand" relations betwen entities 
of the data model.

This is what is shown in your enumeration using the 
src="cocoon:/enums/styles.xml". You introduce this for enumerations 
only, but I think we should widen it to any kind of data type, as 
expanding relations is a major hassle when writing web applications and 
it is needed very often (building popups, master/detail views, etc).

More on this later (still late on projects I left before going to Ghent...)

Sylvain


Bertrand Delacretaz wrote:

>--- 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.
>
>--- ASSUMPTIONS ---
>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 
>used.
>
>-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 -->
>  <data-types>
>    <data-type
>      name="musical-style"
>      class="beaff.enumeration" 
>      src="cocoon:/enums/styles.xml"
>      string-converter="myapp.formats.StyleFormatterAndParser"
>    >
>    </data-type>
>  </data-types>
>
>  <!-- reusable field definitions -->
>  <field-types>
>    <field-type name="artist" data-type="myapps.beans.Artist"/>
>  </field-types>
>
>  <!-- application data model -->
>  <beans>
>    <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>
>
>    <bean name="Artist">
>      <field data-type="java.lang.String" name="name" required="true"/>
>    </bean>
>  </beans>
>
></data-dictionary>
>
>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... ;-)
>
>  
>


-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org