Re: Tuning KVO validation.
Re: Tuning KVO validation.
- Subject: Re: Tuning KVO validation.
- From: mmalcolm crawford <email@hidden>
- Date: Thu, 26 Feb 2004 03:18:28 -0800
On Feb 26, 2004, at 2:39 AM, Sscar Morales Vivs wrote:
Before anyone complains, I'm going to file an enhancement request
about this ;o)
Before you do... :-)
As I see it, validation is the responsibility of the model, and the
validate<key>:error: methods allow for implementing it nicely.
However, the place for responding to the validation error should be
the controller layer, as the response depends on the application logic
and flow. On a failed validation, there should be some delegate
method called or notification sent by whoever called the validation
method.
As it stands at the moment, the response *is* at the controller layer
(you can readily enough get an alert panel if a value fails
validation).
The validation method returns a BOOL directly to the caller, so there
is no need for a delegate in the strict sense you suggest here.
I'd personally vouch for a delegate method for the NSController (I
guess they'll get delegates sometime in the not so far away future)
like the following:
- (void)validationFailedForKey:(NSString*)theKey error:(NSError*);
And/or having a delegate for the controls like the following:
- (void)validationFailed:(NSError*);
or
- (void)validationFailed:(NSNotification*) if notifications were used.
To make the API useable, you'd need minimally to add the object -- or
objects -- that failed (the failure might be the result of applying a
change to a multiple selection of an array controller). It might also
be useful to know what controller sent the message (typically a
delegate message should contain the sender as one of the arguments).
It might also be worth allowing for the possibility of multiple keys
failing simultaneously: (a) Sometimes you might want to defer
validation until an entire form has been filled in, although I think
I'd recommend against that; (b) It would be useful if you could allow
for combinations of values to fail. The classic example of (b) is:
BOOL hasDrivingLicense;
float age;
hasDrivingLicense = TRUE; // valid
age = 10.0; // valid
if (hasDrivingLicense && (age < 16.0))
{
// invalid
}
This latter case should have a validation method of its own (we could
call it, 'validateForSave' :-) ... feel free to file an enhancement
request for this independently!
Put all this together and the API becomes more complex.
- (void)controller:(NSController *) validationFailedForObject:(id)
forKeys:(NSArray *) withErrors:(NSArray *)
Or you might put the objects, keys, and errors into an array of
dictionaries, or...
mmalc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.