On Fri, May 13, 2011 at 10:24 AM, Sean McBride <s...@rogue-research.com> wrote: >>Bindings are also helpful when there are logically >>multiple KVO observations that need to be made. But often times that's >>done more simply with a regular property. > > I have found bindings very helpful for supporting undo, as model changes > are automagically updated in the UI. But sometimes they are a PITA. :)
Well, strictly speaking bindings have nothing to do with undo. They're just a protocol for telling an object, "Hey, that thing you call the Foo binding? Do whatever magic you need to do to hook it up to this keypath on this object over here." 99 times out of a hundred, the object in question is just going to interpret that to mean "add myself as an observer for the provided keypath on the provided object, and when I get -observeValueForKeypath:::, use that value to update my foo property." (I realize this is probably very old hat for you and many readers of the list, but it took me an incredibly long time to get this point, and I suspect many list readers are also at varying stages of bindings comprehension.) But if you're implementing the whole kit and caboodle, there's usually no advantage to adopting the bindings API. For example, we have a custom view that has three or four bindings on it. You can't use this view without a delegate that is a subclass of a certain type. At this point, the bindings are useless to us, because our -setDelegate: implementation looks like this: - (void)setDelegate:(DelegateClass *)delegate { [self bind:@"binding1" toObject:delegate withKeyPath:@"constantKeyPath" options:nil]; [self bind:@"binding2" toObject:delegate withKeyPath:@"anotherConstantKeyPath" options:nil]; // etc. } Meanwhile, -[CustomView bind::::] just looks like this: - (void)bind:(NSString *)binding toObject:object withKeyPath:keypath options:(NSDictionary)options { if ([binding isEqualToString:@"binding1"]) [object addObserver:self forKeyPath:keypath options:0 context:Binding1Context]; else if ([binding isEqualToString:@"binding2"]) [object addObserver:self forKeyPath:keypath options:0 context:Binding2Context]; // etc. } Because we control both sides of the equation, bindings really don't help us here. We could just as easily call -addObserver:::: from within -setDelegate:. If we supported arbitrary delegate objects, or we were releasing this view as part of our public frameworks, the bindings API might be more worthwhile. But right now it's a vestige from when we didn't require a certain delegate class. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com