cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Date Thu, 23 Sep 2004 15:34:56 GMT
Hunsberger, Peter wrote:

> Vadim Gritsenko <> writes:
>>Hunsberger, Peter wrote:
>>>why would you ever do validation on a field that the user cannot 
>>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.

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


View raw message