cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject RE: forms validation question
Date Tue, 01 Jun 2004 21:38:55 GMT
On Tue, 2004-06-01 at 23:07, Hunsberger, Peter wrote:
> Bruno Dumon <bruno@outerthought.org> writes:
> 
> As I've noted previously, we've got a proprietary forms system and I
> don't have much experience with cForms.  However, our experience may be
> useful to you (feel free to disregard!).

Always appreciated!

> 
> We allow multiple templates per form model. Basically we treat them both
> as metadata and create a merged instance specific metadata model as
> needed.  This allows templates to customize generic form objects giving
> you much more back end reusability and allowing you to exploit XSLT for
> custom rendering much more easily.  To do this we couple the validation
> rules to the template and not to the form model, thus you avoid the
> issues of having to merge the models at validation time. Our Validation
> rules are a Schematron skeleton that gets converted into normal
> Schematron via XSLT at validation time (via a Cocoon pipeline).
> Essentially, the presentation template has a link to the validation
> template.

The way I see it (currently), the combination of a CForms model and
template is what the template is in your system. CForms doesn't try to
replace the backend.

I see in fact two different uses of the form framework:

 * smaller applications where the required CForms forms are defined ad
hoc. This is what lots of people are doing.

 * applications whereby all fields and screens are defined in the
backend, usually a large amount of them, and usually adjustable by the
customer of the application. In this case the CForms form definitions
and templates can be generated dynamically based on information from the
backend, and CForms then simply functions as the thing that actually
handles the user interaction.

For a long time I had mainly the first scenario as use case, but it just
happens that (potential) customers we've been in contact with often need
the second case. Due to the declarative nature of CForms (which was
originally mainly to make it usable by 'non-programmers'), it is
actually quite easy to generate these CForms from backend data. With
typical Java form handling frameworks one would need to generate and
compile Java code to do this kind of stuff.

OTOH, there are also concrete plans to add widget repository
functionalities to CForms itself, so that for people who directly use
CForms, it will also become possible to reuse widget definitions across
multiple forms.

> 
> We do allow for widgets to be specified as mandatory at the form level,
> but for those that are not mandatory, the template writer can choose to
> include them as they see fit. 
> 
> Don't know if you can do any of this with cForms, but it's certainly
> proved very powerful for us...
> 
> An example for us is a Radiation therapy form.  We support over 30
> possible widgets, but no single user of the form wants to see them all.
> For many treatment protocols we show less than 10. 

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message