Re: The problem with bindings
Re: The problem with bindings
- Subject: Re: The problem with bindings
- From: Gwynne <email@hidden>
- Date: Thu, 29 Jul 2004 16:03:48 -0400
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.