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 Thu, 23 Sep 2004 18:33:41 GMT
Vadim Gritsenko <> writes:

> Hunsberger, Peter wrote:
> > Vadim Gritsenko <> writes:
> > 
> >>Hunsberger, Peter wrote:
> >>
> >>>why would you ever do validation on a field that the user cannot
> >>>change?
> >>
> >>There is an example. That's exactly how AggregateWidget works. It
> >>consists out of several visible widgets and one invisible (or 
> >>vice versa 
> >>- depending on direction). Invisible one gets value by 
> >>aggregated values 
> >>of visible fields, and then it can run its own validation. 
> >>And there are 
> >>scenarios when separate values are visible, but aggregated is not.
> > 
> > 
> > That sounds like the scenario where you're using JavaScript 
> to update 
> > the hidden field.
> No. AggregateWidget's "invisible" field is not rendered to 
> the client at 
> all. Please take a look at the Cocoon's samples webapp.

Ok, so that means the aggregation is done on the back end where all the
data is available to you in any case?  Looking in samples it's not clear
what you're suggesting to look at...

> >  As I said, in that case it should be possible to
> > validate the component parts and not the aggregate.  Eg. 
> For the case 
> > of aggregating three component parts of a phone number, I think it 
> > makes more sense to give an error of "Invalid area code" 
> than "Invalid 
> > phone number"...
> What if area code is valid but number does not exist?
> > So the question becomes why do you need to validate the 
> aggregate and 
> > not the component parts?
> See above. Same with SSN, EIN, etc.
> >>Similar things could be employed by application developers -
> >>and that's 
> >>when they might use this invisible widget.
> >>
> >>And even if widget is not visible by itself, you can always 
> show it's
> >>validation errors.
> > 
> > 
> > I'll take your word for it, but a real life use case might help 
> > general understanding...
> Phones, credit card numbers, SSN, EIN, ITIN, etc, all can be valid in 
> parts but not valid as a whole.

For most of these cases you should probably use a single field for data
entry. Certainly, for things like a credit cards where the number of
valid digits depend on the card issuer I'd probably use a single field.
For SSN and EIN I can't see any reason for multiple fields either. Even
phone numbers can be tricky of you're allowing for international
numbers. But even if I considered any of these valid use cases it's
basically irrelevant to the point at hand: 
maybe it's just because I'm biased towards Schematron, but I'd still
rather have the component pieces available to the validation step and
let it decide how to combine the data for the purposes of validation.
To me, an error message saying "Invalid area code: '9o1'" is more
meaningful than an error message saying "Invalid phone number:

View raw message