cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: forms validation question
Date Tue, 01 Jun 2004 21:56:26 GMT
Bruno Dumon <> writes:

> On Tue, 2004-06-01 at 23:07, Hunsberger, Peter wrote:
> > Bruno Dumon <> 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.

Hmm, not sure.  Our form model is independent of the back end and how
the data is produced.  

I think the biggest difference is that we have three components: a
metadata object model (similar to half the cForms form model), the
presentation template (similar to the cForms template) and a separate
validation template (the other half of the cForms form model), but
coupled to the template.  It's a little more work to maintain but it
separates out the concerns completely.

> 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.

Something our system is definitely not designed for!

>  * 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.
This is precisely what our system is designed to do.

> 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.

I have some thoughts on how you can do a generalized repository (a
generalization of our generalizations).  I'll have to think about
whether it's anything anyone could actually use without getting lost in
the generalizations and resulting abstractions...


View raw message