Hunsberger, Peter wrote:
Vadim Gritsenko <[EMAIL PROTECTED]> 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.
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.
Vadim
