On 21.Nov.2002 -- 10:04 AM, Bertrand Delacretaz wrote:
> 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.
>
> -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.
If the classes are only used to hold data, that could be done with a
DOM-like structure as well. Access could be done through jxpath.
> -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.
Personally, I prefer the configuration approach. This allows to put
everything in a database and have dynamic forms.
The DD could be used to generate javascript code that does the
validation. Since the client understands javascript (or nothing) the
generated scripts can be used for client side validation as well. We
are already in the great position to be able to write actions in
javascript IIRC. So feeding this generated code to a javascript action
could be used to do the actual validation.
Of course I'd be happy as well if some java was produced and compiled
on the fly. Many clients can use java for form validation as well.
>
> 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>
The DD should / could contain error messages as well. AFAIK xforms
does that already. Two types of error messages would be nice: a "short
error" and a "long error".
> 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.
>
> 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... ;-)
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
