Re: The problem with bindings
Re: The problem with bindings
- Subject: Re: The problem with bindings
- From: mmalcolm crawford <email@hidden>
- Date: Thu, 29 Jul 2004 22:19:57 -0700
On Jul 29, 2004, at 1:03 PM, Gwynne wrote:
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.
Doesn't crash for me -- the window closes correctly.
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.
Have you filed bug reports?
Also, I've found myself trying "too" hard to use bindings everywhere.
That's user error...
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).
(a) It's not clear to me that, primarily in the context of bindings,
it's generally appropriate to have target/argument bindings for, say,
switch buttons, since they typically reflect distinct state rather than
afford an opportunity to effect an action. That said,
(b) Have you filed enhancement requests?
Don't let anyone kid you that bindings are the solution to end all
solutions for user interface manipulation.
... nobody has suggested that bindings are the "solution to end all
solutions" -- it's typically clear that a combination of bindings and
"traditional" patterns is expected.
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.
It's not clear to me that this should be expected behaviour -- all that
is sent (and precisely what is documented(*)) is a change
*notification*. If the value of key2 is actually changed, the process
of its changing should send its own notification and hence send a
notification for key3.
(*)
+ (void)setKeys:(NSArray *)keys
triggerChangeNotificationsForDependentKey:(NSString *)dependentKey
Register the fact that invocations of
willChangeValueForKey:/didChangeValueForKey: and
willChange:valuesAtIndexes:forKey:/didChange:valuesAtIndexes:forKey:
for any key in 'keys' should automatically invoke the same methods for
the dependentKey.
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.
Have you filed an enhancement request?
Adopting bindings correctly requires a Major change in how you think
of and structure your model,
If this is the case, it would suggest that your coding practices have
hitherto not followed well-established Cocoa guidelines.
and if you're not careful you can end up making your code more
complicated.
I would hope that any developer will always be careful.
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.