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 <bruno@outerthought.org> writes:

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

Cool...

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

<snip/>


Mime
View raw message