Re: Is willChangeValueForKey: always needed?
Re: Is willChangeValueForKey: always needed?
- Subject: Re: Is willChangeValueForKey: always needed?
- From: David Catmull <email@hidden>
- Date: Fri, 17 Nov 2006 10:43:02 -0800
On Nov 16, 2006, at 10:11 PM, Chris Hanson wrote:
Yes.
I'm curious: Why? What does it do?
Instead of having a calculated controller or model key take the
values to use for its calculation directly from views/controls, you
should have your views/controls bound to some sort of model- or
controller-layer attributes, and then have whatever needs to take
this calculated value bound to its corresponding key.
I did, I was just trying to simplify my explanation :) I should have
said it looks at the corresponding keys in the object controller.
- The unit test calls setValue:forKeyPath: on an
NSObjectController used to store the settings for my window's
controls
A controller mediates between model and view objects, it shouldn't
be storing things on its own.
Then why does it contain a dictionary?
There are a couple of issues with the above. The first is, as I
pointed out, is that you're expecting a property of a view to
change immediately after programmatically manipulating the model/
controller level object it takes the value of the property from.
So when does it happen? Why doesn't it happen immediately?
I sometimes wish I worked at Apple just so I could have access to the
bindings implementation code and finally understand what's going on :)
Thanks for the infoForBinding: tip. For some reason I was thinking
that returned an opaque object, but I guess I had it confused with
something else.
--
David Catmull
email@hidden
http://www.uncommonplace.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden