Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The problem with bindings

On 31 Jul 2004, at 01:20, Allan Odgaard wrote:

On 31. Jul 2004, at 1:34, Steve Sims wrote:

Let's take a couple of real examples here to illustrate what I'm after.
[...]

Okay, so you only want the cascade when explicitly doing:
[fontParams setValue:newWidth forKeyPath:@"size.width"];

But not when doing:
[[fontParams valueForKey:@"size"] setValue:newWidth forKey:@"width"];

Actually I think what I'm after is more that the cascade should happen when doing:
[dataModel setValue:newWidth forKeyPath:@"fontParams.size.width"]
which I presume is what the bindings system is doing, since the key path I use in my binding is "fontParams.size.width".

I wasn't really thinking about the second case you give here... "size" probably should tell anyone that's observing it that it's changed. That shouldn't be difficult to manage.

I am not sure if you can always enforce the former to happen.

Sure you can - just notify the components of the key path of the change. Since no key path is used in the latter case there's no components of the key path to notify of the change.

I see forKey: and forKeyPath: as being slightly different things, and don't really expect the same behaviour from them... Maybe I'm wrong to think this though.

For example with the views which manage multiple values (menus/comboboxes, tables and the matrix), there is both a content and a contentValues binding, and I am quite sure the view will do something similar to the latter line above -- though probably these views could be changed to manually ensure that change notifications are sent for each component in the key paths.

An interesting point, and I agree the views could be changed to send notifications. This kind of change to bindings/KVO/KVC would be fairly significant and I wouldn't expect it to suddenly start working on 10.3.

It would be so nice to bind to, or observe, "fontParams.size" or maybe "fontParams.size.*" to get all the changes that happen there. I can only speculate as to how easy or hard this would be, but it doesn't feel all that difficult to me.

[...] Right now my UI works by binding to a derived value within my data model, and I use manual observer notification in the setter methods of the dependent keys.

Are you aware of setKeys:triggerChangeNotificationsForDependentKey:? That should probably remove your need for manual observers.

I had found triggerChange... when I was designing my data model but I wanted to do things that were better done with my own custom observers, so I forgot all about it. This could certainly work to help ensure that my model has a bit less UI related code.

If there was a "DependentKeyPath" version then it would be even better, since I could move all of my UI code out of my model and into one of my UI controllers.

Thanks for the reminder.

Steve
_______________________________________________
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>)
 >Re: The problem with bindings (From: Gwynne <email@hidden>)
 >Re: The problem with bindings (From: Steve Sims <email@hidden>)
 >Re: The problem with bindings (From: Allan Odgaard <email@hidden>)
 >Re: The problem with bindings (From: Steve Sims <email@hidden>)
 >Re: The problem with bindings (From: Allan Odgaard <email@hidden>)



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

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.