On Sep 7, 2015, at 12:01 AM, Alex Hall <mehg...@icloud.com> 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
