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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
