Re: self willChangeValueForKey: @"all keys"???
Re: self willChangeValueForKey: @"all keys"???
- Subject: Re: self willChangeValueForKey: @"all keys"???
- From: todd ransom <email@hidden>
- Date: Fri, 25 Mar 2005 13:27:17 -0700
I recently added a mutableKeys method to my base model class and I
think something similar could help you here.
Basically, your object implements a method that returns an array of all
its keys or some subset of its keys, depending on what you plan on
doing. Then you can iterate this array for archiving, KVO, etc. The
nice thing is you have only one place to update when you add keys and
subclasses will automatically inherit.
You can get more detail here:
http://returnself.com/blog/2005/03/09/beyond-bindings-cool-stuff-about-
key-value-coding/
TR
On Mar 25, 2005, at 11:26 AM, glenn andreas wrote:
So I've got a class (an ephemeris that calculates all sort of
information about sun/moon/planets/etc...) that has a whole bunch of
derived values (as in dozens, and probably many more than that later)
that change when a single "master" value changes, and I'd like to use
bindings to update all those derived values when the master changes
(change the time, and everything will have moved)
As I see it, I can either write a boat load of [self setKeys: [NSArray
arrayWithObject: @"master"]
triggersChangeNotificationsForDependantKey: @"key1"] during my
initialize method, or else do a similar thing in when the master value
is set with "willChangeValueForKey:"/"didChangeValueForKey:". Either
way, I need to be constantly updating this to make it longer and
longer (and when I'm done I could possible have keys in the hundred+
range).
To make things worse, if there are additional categories added with
more derived information (so I can add on methods for different sort
of astronomical information), so though I separate the object into
nice distinct categories of functionality, I constantly have to update
the base implementation (which is certainly error prone).
Is there any sort of magic "everything has changed" key? The best
I've come up with is possibly iterating through all the methods of the
object and figuring out if those methods might be accessors (which
seems pretty ugly), and adding them to the
triggersChangeNotificationForDependantKey, but that won't work if
categories are added at run time (since that part is done once). I
could probably also iterate the accessors in my "-setDate:" method,
but that seems, well, even more distasteful than doing it in
"+initialize".
Glenn Andreas email@hidden
<http://www.gandreas.com/> oh my!
Mad, Bad, and Dangerous to Know
_______________________________________________
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
_______________________________________________
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