Re: Observing edits make to a table using bindings
Re: Observing edits make to a table using bindings
- Subject: Re: Observing edits make to a table using bindings
- From: Jonathan deWerd <email@hidden>
- Date: Tue, 20 Jan 2009 17:24:55 -0700
Is it possible [with KVO] to know exactly which array element was
edited, without
registering observers on the entire contents of the array? I figure
it has something to do with the keyPath, but the exact something has
thus far eluded me.
As I see it, there are several ways to get around your problem. The
limits of KVO you are bumping into were probably a good design
decision, but I sympathize! It can sure be annoying.
The "most correct" way IMHO would be to change your model element
class from NSMutableDictionary to your own class, building whatever
logic you want right into it. Not only does it make the MVC gurus here
happy, it saves you from KVO voodoo and its inherent pitfalls/
opaqueness/performance issues. KVO is awesome, but only in moderation
when combined with MVC. Without further ado, here is a demonstration
(you would put "MyKeyValuePair" in the "Class Name" field of
NSArrayController in IB):
@class MyKeyValuePair /*Change the name!*/ {
NSString* name;
NSString* value;
}
@property (copy) NSString* name;
@property (copy) NSString* value;
@end
@implementation MyKeyValuePair
@synthesize name;
@synthesize value;
- (void)setValue:(NSString*)str {
//Do stuff here
}
@end
You could also roll your own controller (by subclassing NSArray
controller or making your own data source). This would be in defiance
of MVC: MVC predicts that fusing controller and model is a path to
failure. I tend to agree. Apple agrees too: their "dumb default" model
is dumb for precisely that reason. Use your own judgement, but I'd shy
away from controller-model unification at the first sign of trouble.
Now, how much cleaner is the MyKeyValuePair class than a glob of KVO
code replete with cryptic options, behind the scenes voodoo, and long
method calls?
:)
---------------------------------
Jonathan deWerd
http://dew0rd.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden