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: Widget states: let's do it (was Re: CForms making widgets invisible)
Date Fri, 24 Sep 2004 21:08:27 GMT
Sylvain Wallez <> writes:

> Hunsberger, Peter wrote:
> >Sylvain Wallez <> asks:
> >
> ><snip>discussion on hidden etc.</snip>
> >  
> >
> >>>I also think we can find a better names:
> >>>
> >>>formInclusion --> show, render, presentation, view, [fill a
> >>>      
> >>>
> >>new name]
> >>    
> >>
> >>>notIncluded -->  Excluded validation --> validate
> >>> 
> >>>
> >>>      
> >>>
> >>Ok, maybe the "phantom" state isn't a good idea after all.
> >>But I still 
> >>consider that "hidden" is a view concern since it has no 
> >>impact on the 
> >>request processing.
> >>
> >>Now I have a problem with separating state and validation:
> >>what does it 
> >>mean if an active widget has validate="false". Does it mean that we 
> >>allow the user to validate a form where she has input invalid data? 
> >>Doesn't seem good to me...
> >>    
> >>
> >
> >It means simply that you don't perform validation on any input from 
> >that widget, the user is free to put what ever data they 
> want into it.
> >
> >In our system we default to requiring validation but allow 
> the analysts 
> >to mark a field as not requiring any validation.  They sometimes do 
> >this for comment fields or optional pick lists.
> >  
> >
> And what's the default validation for these comments and pick lists?

Umm, no validation means no validation, none, nada...

> Does this mean that a particular user category is allowed to 
> violate the 
> constraints? 

What constraints?  The comments boxes max have max chars set, but
otherwise they are text strings dumped into clobs in the database.  The
pick lists are preconstrained to have id's from type tables already in
the database (by the very construction of the pick lists we know the
values to be valid if any are chosen).

> And what if you want _some_ of the constraints to be 
> optional, but not all (e.g. a date that must always be in the future, 
> but can be outside of the specified maximum)?
Then you wouldn't make validation=false for the fields you want to
validate.  Again, we use Schematron, so we just write a validation rule
that says exactly that for the field in question.  If we've written a
rule, then we are doing validation (more or less)...

> It seems to me like a particular implementation of a validator: a 
> container validator, that would call its children only if 
> some condition 
> is true (in your case user role + a flag indicating relaxed 
> constraints)

I don't see turning validation off as being generally useful at any
level above the individual form field.  However, we also do not stop
people from shooting themselves in the foot if they want to; there may
be use cases we haven't considered where not having group level
validation makes sense...

View raw message