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:07:06 GMT
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!).

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.

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. 

> 
> On Sat, 2004-05-29 at 13:20, BURGHARD Eric wrote:
> > Hi,
> > 
> > I've got a simple question (request) about how the form are 
> validated.
> > 
> > It seems that for the moment, the whole model is validated 
> even if we 
> > don't use all the widgets in the template.
> 
> What you're doing here isn't supported, and you've just found 
> out one of the reasons why.
> 
> > 
> > So is there a reason to check the rules of all the widgets 
> instead of 
> > the rules of the submitted widgets (from the template) ?
> 
> I don't have time right now to explain this deeply (or to 
> think about it deeply), but I think the widget tree should 
> always be completely processed.
> 
> Just to drop some things:
> 
>  * the form can't know which widgets the template would 
> decide to display [and thus which widgets are the 'submitted 
> widgets'], unless we would encode that information in the 
> request (ie. by adding a hidden input field for each widget 
> to indicate if it is there)
> 
>  * but: it should be the server-side form model which expects 
> certain widgets to be there, instead of the other way around 
> (ie the request saying which widgets it decides to submit)
> 
>  * validation can do checks between multiple widgets, how 
> should this deal with the possibility of arbitrary widgets 
> not being displayed?
> 
>  * what to do with required widgets? Is it because the 
> template author decides that a widget should not be 
> displayed, that is suddenly becomes not required?
> 
>  * In general, I don't think it is the template writer who 
> decides which widgets to display. There's been suggestions 
> about how one form model should be combinable with multiple 
> templates which display different subsets of the widgets, but 
> this doesn't make sense to me. Having one form model for each 
> separate form makes things much easier. Besides, it's not 
> like the template author could simply decide to move one 
> widget from one page to another, since the controller logic 
> (and also the form model with its validation logic) have 
> expectations about widgets actually being there on a page. As 
> an example, take the amazon checkout
> wizard: I don't believe it would be possible to randomly move 
> widgets between its different pages.
> 
> The solution lies, I think, in the union widget (which we 
> still need to finish up -- I don't know its current state). 
> You can think of it as a switch between multiple (groups of) 
> widgets. You could then define a union between "the widget" 
> and "no widget", and switch the union to the desired case.
> 
> Another solution may be the proposed widget states (see 
> somewhere on the wiki), though I don't have that fresh in my 
> mind right now.
> 
> -- 
> Bruno Dumon                             http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> bruno@outerthought.org                          bruno@apache.org
> 
> 
> 


Mime
View raw message