macOS NSObectController binding question

[mdeh]

Getting started with Bindings. I am going through Hillegass, but I constantly find myself darting off at a tangent, to figure out what he means. But they speak about him in religious terms, so I am sticking with it.
This little tangent was to get a somewhat deeper insight into bindings.
It's an example from the Apple documentation.
http://developer.apple.com/documentation/developertools/Conceptual/IB_UserGuide/ConnectionsandBindings/ConnectionsandBindings.html

I got the example to work, but I am confused by 2 concepts

Figure 6-8 shows the general layout


The view that is confusing is this one.


Specifically, the "Controller Key" selection. The documentation says this about selection.

Return Value
A proxy object representing the receiver’s selection. This object is fully key-value coding compliant, but note that it is a proxy and so does not provide the full range of functionality that might be available in the source object.

Now...I am not even sure if this is relevant, but if it is, I wonder if someone could explain this. ( I notice I am not alone in this as many have asked before but it has almost never been answered with a good answer)

Secondly...using the controller, I see that the NSTextField is directly bound to "quantity" in the Model Key Path. I know they say that the NSOC acts as a proxy for "MyDocument", but could someone perhaps just elaborate on this too.

Much appreciated.

 

[eddietr]

Now...I am not even sure if this is relevant, but if it is, I wonder if someone could explain this. ( I notice I am not alone in this as many have asked before but it has almost never been answered with a good answer)

Well, "selection" refers to the currently selected object. In the case of a plain old NSObjectController, "selection" is really just the one object that the controller is bound to.

"Selection" becomes more interesting when you use the subclasses of NSObjectController such as the array and tree controllers. Then you have multiple objects being controlled and selection refers to the currently selected one.

Secondly...using the controller, I see that the NSTextField is directly bound to "quantity" in the Model Key Path. I know they say that the NSOC acts as a proxy for "MyDocument", but could someone perhaps just elaborate on this too.

So the controller in this case is bound to the property called "entry". And then in your binding you specify a key called "quantity".

So you are asking for the "quantity" of the bound object "entry". So the end result is a reference to "entry.quantity".

Or put another way, "selection" is a proxy for the entry object. So you can also think of this as "selection.quantity".

In reality, the controller has it's own little dictionary where it does that lookup. But that's an implementation detail that doesn't affect how you interact with it. If for some reason you *really* need the actual entry object then you can use selectedObjects to get it. But that generally sort of defeats the purpose of using the controller.

Hope that helps?

 

[mdeh]

Well, "selection" refers to the currently selected object.

Firstly, thank you as always for taking the time to respond. Always appreciated.

OK...so let me clear up some syntax.

From what you say below, the "bound to" object refers to the property of the model. How do you describe the relationship of the controller to the Control in the view...initially I thought that your were referring to this.
.

Or put another way, "selection" is a proxy for the entry object. So you can also think of this as "selection.quantity".

Ok...this makes what I read earlier make a lot more sense.

Thanks eddietr

 

[eddietr]

Firstly, thank you as always for taking the time to respond. Always appreciated.

No problem at all.

OK...so let me clear up some syntax.

From what you say below, the "bound to" object refers to the property of the model. How do you describe the relationship of the controller to the Control in the view...initially I thought that your were referring to this.
.

In this case, I would say the text field is bound to the object controller. And the object controller is bound to the entry property of the document.

 

[mdeh]

No problem at all.



In this case, I would say the text field is bound to the object controller. And the object controller is bound to the entry property of the document.

May I follow up with some more issues...I did not wish to start a new thread.
In advance, apologies if this is at all repetitive...if it is , it is my lack of understanding.

From Apple's oft quoted ( although now dated ) Currency Converter with Bindings.

http://developer.apple.com/documentation/Cocoa/Conceptual/CurrencyConverterBindings/04buildingrel/buildingrelations.html

Establish the Model-Controller Relationship
........you need to associate it with a model object by specifying which model object it controls. You .... connect the controller to the model object....There are a number of ways to set a controller’s content, the easiest of which is to set its content outlet ....... you are telling the controller to use the data that object provides and also to provide that object with data........... Simply setting a controller’s content outlet to a model object does not provide the controller with enough information to know how to access the data in the model object. The most important attributes of a controller are the model keys it exposes to the views. .......... You expose model keys as follows:

Part of understanding for me is trying to boil down verbose/complicated bits of information to some small nugget that encapsulates it ( no pun intended! ).

It seems to me that I am simply "initializing" the controller with the models ivars...it's almost as if I had written the view's "IBOutlets" into the controller. The other part that I would like to get some clarity on is the line that says ".There are a number of ways to set a controller’s content, the easiest of which is to set its content outlet". I am sure I will run into those soon, but it would be nice to be able to put this into perspective now.

So, first question is how do you conceptualize this step?

Every binding provided by Cocoa bindings includes at least three aspects: Bind to, Controller Key, and Model Key Path. The Bind to aspect ...........

The Controller Key aspect specifies the access point in the controller object that the binding uses to get and set data.

The Model Key Path aspect.......

I know that you explained "selection" above, and I would really like to see how this fits in with Apple's explanation of the Controller Key here. I get the first and the third aspects,...well I think I do I would just like to boil that explanation down to something that is another nugget.

By the way, I think I also misunderstood what Apple meant by bindings...which if I know understand it correctly, may also clarify this whole part of Cocoa a little more.


http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html
Here is what they say

A binding is established with a bind:toObject:withKeyPathptions: message which tells the receiver to keep its specified attribute synchronized—modulo the options—........... two aspects to keeping the model and views synchronized:..........

I only saw the issue about 2 aspects to a binding now, which implies , I think KVC and KVO. I had been trying to figure out how KVC could do both synching **and** notifying..OK>..so that is taken care of!

What I do not get is the "—modulo the options—" part...perhaps you could enlighten.

Looking forward to your answers and enlightenment...as perhaps are others who are following this.
With much thanks

 

[eddietr]

Part of understanding for me is trying to boil down verbose/complicated bits of information to some small nugget that encapsulates it ( no pun intended! ).

Yeah, I'm not sure if there is a small nugget in this case. At least not one smaller than what we've already discussed. Or what you've read in the docs. Have you done a lot of MVC work in other languages/frameworks before?

It seems to me that I am simply "initializing" the controller with the models ivars...it's almost as if I had written the view's "IBOutlets" into the controller.

Well, when you create the keys on the controller, you're essentially "reflecting" the model's properties, if you want to think of it that way. But that's just the simplest case of bindings. You can do much more than this (transformations or placeholders, for example).

The other part that I would like to get some clarity on is the line that says ".There are a number of ways to set a controller’s content, the easiest of which is to set its content outlet". I am sure I will run into those soon, but it would be nice to be able to put this into perspective now.

Well, there are ways to set a controller's content programmatically. And you can do that with an object that you've created or you can have the controller create a model object for you. See the docs for NSObjectController for more info on that.

I know that you explained "selection" above, and I would really like to see how this fits in with Apple's explanation of the Controller Key here. I get the first and the third aspects,...well I think I do I would just like to boil that explanation down to something that is another nugget.

I'll have to think of a better way to explain that. "Selection" is just the model that is currently selected (and selection == content for NSObjectController since it's content is just a single object).

There are other built in keys like "canAdd" for example which tell your view if it is possible to add a new object to the controller (again, really only relevant for controllers which control groups of objects like array controllers)

I only saw the issue about 2 aspects to a binding now, which implies , I think KVC and KVO. I had been trying to figure out how KVC could do both synching **and** notifying..OK>..so that is taken care of!

Yeah, binding uses KVO. And KVO requires that the object being observed is KVC.

What I do not get is the "—modulo the options—" part...perhaps you could enlighten.

Oh, that's just someone over there using a slightly too cute way to say that the "syncing" in a binding is subject to the conditions of the options. So, for example, you have placeholders or you may have continuous versus non-continuous bindings. Or you may have transformations. So the outcome of the "sync" depends on all those things.

Hope that helps? I get the sense you still don't quite get it, because you've asked the same thing a couple of different ways. (Not a negative thing at all, I'm just trying to solve it) So I'm trying to think of a way to make it more clear. Have you worked through an example or two of your own yet?

 

[mdeh]

Hope that helps? I get the sense you still don't quite get it, because you've asked the same thing a couple of different ways. (Not a negative thing at all, I'm just trying to solve it) So I'm trying to think of a way to make it more clear. Have you worked through an example or two of your own yet?

True...
But, this does help. I think your last suggestion is the way to go. It's possible, that I am overthinking it too. Thanks eddietr....and thanks for sticking with me.

 

[eddietr]

True...
But, this does help. I think your last suggestion is the way to go. It's possible, that I am overthinking it too. Thanks eddietr....and thanks for sticking with me.

Right, it may be you are overthinking it. Work out an example for yourself and see if it makes sense to you.

You can override setValue:forKeyPath in your model class and set a breakpoint on that method. You may find that enlightening.

 

[mdeh]

Right, it may be you are overthinking it. Work out an example for yourself and see if it makes sense to you

Firstly a public thank you for sticking with me. There are a few but dedicated members who do not seem to flinch from answering these, oft repetitive questions from newbie members like myself. We owe all of you a great debt of gratitude.

Your answers have guided me to the breakthrough I needed. The problem, for me, ( not sure about others) is that often one is not sure of the correct **question** to ask. For me it finally came down to understanding the role of "content" of controllers versus "selection", which has a really nice diagram in the Apple docs here http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/MessageFlow.html

I am sure I am not done with questions yet!! ( ) but thanks for helping me get to a point of seeing the forest, at last!

 

[eddietr]

Firstly a public thank you for sticking with me.

And a public "you're welcome". Let us know how your binding experiments work out.