Re: Getting started with Cocoa Bindings in My Project?
Re: Getting started with Cocoa Bindings in My Project?
- Subject: Re: Getting started with Cocoa Bindings in My Project?
- From: Ken Thomases <email@hidden>
- Date: Mon, 07 Sep 2015 23:20:16 -0500
On Sep 7, 2015, at 12:01 AM, Alex Hall <email@hidden> wrote:
> Next is the problem of accessing the current MyKVOCClass object from the view controller, where my model is instantiated. I'll need a computed property for this, which I'll call currentModelArray. This should return a reference to the currently active array in my model. You both suggested I implement
> private func keyPathsForValuesAffectingCurrentModelArray() -> Set<String> {}
> in addition, so that as I change the value of the currently selected object in my model, the controller is notified. At least, that's how I understand the purpose of this method. The set this method returns contains strings; are those all the possible values the computed property can ever hold, or are they something else entirely? I'm just not clear on which strings to provide here--what you referred to as "input properties".
In later emails I took the liberty of renaming this property currentTweetStream. You had said you have a property currentTab that is a string used to look up the appropriate TweetStream (as I've named it) in your dictionary. So, the set returned by keyPathsForValuesAffectingCurrentTweetStream() should include "currentTab" (a string containing the name of the currentTab property) and, possibly, the name of the dictionary mapping names to TweetStream objects. It would only need to include the name of the dictionary if that dictionary may change over the life of your TweetDataController. Also, any properties named there must only be modified in a KVO-compliant manner and must be "dynamic". (If you change the dictionary over time, we'll need to discuss how to do that in a KVO-compliant manner.)
Basically, these keyPathsForValuesAffecting<Key> methods should list the key paths of any properties used in the implementation of the computed property getter. They are the "inputs" to the computation of the computed property. Your implementation is likely to look some like "return nameToTweetStreamMap[currentTab]", so the set would be ["currentTab", "nameToTweetStreamMap"].
Finally, keyPathsForValuesAffecting<Key> methods need to be class methods and dynamic. The template that Charles provided has those attributes and you need to preserve them.
> Alright, we have a KVO-compliant storage system in my model, and we have a properly configured computed property that will tell the controller (here referring to the ArrayController) where in my model to look. Time to connect things.
>
> First, I'd look at the bindings inspector for the array controller. [...]
Hopefully, I made that clear in my last email.
> Next I'd look at the bindings for my table. I'd want to set the controller to my ArrayController, I don't know the specific words I'd use for keys here, but I'd *not* use any of my own variables, correct? This is all properties of the controller itself. This lets the controller figure out things like how many rows there are, what's selected, and so on.
Yes, this sounds right.
> Finally, repeat the previous step, but for the table cell. As before, I'm now using all properties of the controller, nothing *I* made anywhere.
No, this is wrong. Assuming the cell view is an NSTableCellView and it has an NSTextField as a subclass, you would bind the text field's Value binding to the containing table cell view with a model key path of "objectValue.<some property of your Tweet class>". If your Tweet class has a "text" property and that's what you want to show in the table, the model key path would be "objectValue.text".
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden