Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: The problem with bindings
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The problem with bindings

On Jul 29, 2004, at 3:05 PM, Steve Sims wrote:
Basically, it comes down to this: bindings are very hard to debug. You can't set a breakpoint, so you are left guessing at what is happening based on an obscure error message from an exception thrown deep in the Cocoa frameworks. Anyone else have this problem?
The question in my mind here is what is there to debug?

I've never had the bindings system itself crash on me. As I said above the problems I usually faced have been simple problems in my UI definition. Otherwise my problems have been with my data model, and those can be resolved with putting breakpoints inside the appropriate setter methods.

Warning: This email gets a little rant-ish. Read at your own risk.

I've had bindings crash on me. Create a window in IB. Put a button in it. Create a subclass of NSObject and instantiate it. Hook it up as the contentObject of an NSObjectController. Put an window outlet in the object and hook the window up to it. Bind the button's target to NSObjectController->selection.window with the performClose: selector, and bind the first argument to NSObjectController->selection.window too. Now try running a program (not IB's simulator) that uses this window. Click the button and crash. Now change the argument binding to just NSObjectController->selection. No crash. Try hooking a window's "visible" binding to anything and then running IB's simulator on that window. Try clicking a button that has target and argument bindings in IB's simulator and watch IB explode.

Also, I've found myself trying "too" hard to use bindings everywhere. There are times when the outlet-connection model works better for things, and there are times when bindings are better. Finding the happy medium where you make maximum effective use of both is tricky, especially since there are several things you can't bind in IB even though it'd make amazing sense to bind them (say, the target/argument bindings of most button types or any text field). Don't let anyone kid you that bindings are the solution to end all solutions for user interface manipulation. Something as simple as this doesn't work like you'd expect:

+ (void)initialize
{
[self setKeys:[NSArray arrayWithObject:@"key1"] triggerChangeNotificationsForDependentKey:@"key2"];
[self setKeys:[NSArray arrayWithObject:@"key2"] triggerChangeNotificationsForDependentKey:@"key3"];
}

Now [someObject setValue:anyValue forKey:@"key1"]. key2 will be updated, but no change notification for key3. Also, you can't do this:

[self setKeys:[NSArray arrayWithObject:@"singleKey"] triggerChangeNotificationsForDependentKeys:[NSArray arrayWithObjects:...]];

Or in English, you can't easily make multiple keys dependent on a single key; you have to call [self setKeys:triggerChangeNotificationsForDependentKey:] with the same array over and over.

Adopting bindings correctly requires a Major change in how you think of and structure your model, and if you're not careful you can end up making your code more complicated.

-- Gwynne, key to the Code that runs us all
Email: email@hidden
Web: http://musicimage.plasticchicken.com/
_______________________________________________
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.

References: 
 >The problem with bindings (From: Drew McCormack <email@hidden>)
 >Re: The problem with bindings (From: Steve Sims <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.