14

Although I have searched for many information about Cocoa Bindings, I still remain relatively unsatisfied with information I have and got. It seems that topic is somewhat troublesome for many and many are just avoiding this pattern, which I believe should not be.

Of course, it may seem that bindings are sometimes too complicated or perhaps designed with too much overhead...

However, I have one very direct and specific question: Why is NSObjectController needed if I can establish bindings directly?

For example, the code:

[controller bind:@"contentObject" toObject:self withKeyPath:@"numberOfPieSlices" options:nil];

[slicesTextField bind:@"value" toObject:controller withKeyPath:@"content" options:nil];
[stepperControl bind:@"value" toObject:controller withKeyPath:@"content" options:nil];

Does exactly the same as: 

[slicesTextField bind:@"value" toObject:self withKeyPath:@"numberOfPieSlices" options:nil];
    [stepperControl bind:@"value" toObject:self withKeyPath:@"numberOfPieSlices" options:nil];

In my case here, we are talking about property of the class inside which everything is happening, so I am guessing the need for NSObjectController is when:

  • key path for controller is object and binding of other controls is needed to its properties, not to its value as with primitives and wrappers around them is the case (numberOfPiesSlices in my case is NSInteger)

  • or when binding is needed from other outside objects, not only between objects within one

Can anybody confirm or reject this?

Demitri
  • 13,134
  • 4
  • 40
  • 41
mbpro
  • 2,460
  • 3
  • 22
  • 37

2 Answers2

12

One of the benefits/points of bindings is to eliminate code. To that end, NSObjectController etc. have the benefit that they can be used directly in interface builder and set up with bindings to various UI elements.

Bindings only represent part of the functionality on offer. The *ObjectController classes can also automatically take care of a lot of the other more repetitive controller (as in Model, View, Controller) code that an application usually needs. For example they can:

  • connect to your core data store and perform the necessary fetches, inserts and deletes
  • manage the undo / redo stack
  • Pick up edited but not committed changes to your UI and save them (e.g. if a window is closed while focus is still on an edited text field - this was a new one to me, I found it from mmalc's answer in the thread below).

If you're doing none of this, then it probably isn't worth using NSObjectController. Its subclasses (NSArrayController etc) are more useful.

Also see here for a discussion of your exact question!

jrturton
  • 118,105
  • 32
  • 252
  • 268
  • 1
    UI elements' bindings can be bound to an object controller or to something else, as it says in the question. So what code does an object controller eliminate? – Peter Hosey Dec 27 '11 at 18:15
  • The code where you set up the binding in the first place - you can do this in IB with an NSObjectController. Unless I am mistaken and you can set up bindings in IB with non-*controller objects? Happy to be corrected if so. – jrturton Dec 27 '11 at 18:18
  • 1
    You can't set up a binding on a plain object in IB or the nib editor, but you can bind *to* a plain object. What purpose is there to create an object controller other than to bind to it—and if none, why not bind the control directly to the object that it needs backing it? – Peter Hosey Dec 27 '11 at 22:56
  • Thanks, @jrturton for sending me the link. I somehow missed it....However, The question is not answered in full. I hope we shall have more discussion on this subject. I also wouldn't say NSObjectCOntroller eliminates the code. My example above shown even slight overhead created using it... – mbpro Dec 28 '11 at 07:04
  • @PeterHosey - thanks for pushing me to improve on what was a pretty half hearted initial answer. What else have I missed? ;) – jrturton Dec 28 '11 at 08:44
  • Thanks, Peter! THis is resourceful answer. :) – mbpro Dec 28 '11 at 09:32
  • Wouldnt binding directly be a violation of apples MVC paradigm ? – Samhan Salahuddin Dec 12 '12 at 04:52
5

Why is NSObjectController needed if I can establish bindings directly?

I read this question a few days ago while looking for some information about NSObjectController, and today while continuing my search, I found the following passage which seemed relevant to the question:

There are benefits if the object being bound to implements NSEditorRegistration. This is one reason why it’s a good idea to bind to controller objects rather than binding directly to the model. NSEditorRegistration lets the binding tell the controller that its content is in the process of being edited. The controller keeps track of which views are currently editing the controller’s content. If the user closes the window, for example, every controller associated with that window can tell all such views to immediately commit their pending edits, and thus the user will not lose any data. Apple supply some generic controller objects (NSObjectController, NSArrayController, NSTreeController) that can be used to wrap your model objects, providing the editor registration functionality.

Using a controller also has the advantage that the bindings system isn’t directly observing your model object — so if you replace your model object with a new one (such as in a detail view where the user has changed the record that is being inspected), you can just replace the model object inside the controller, KVO notices and the binding updates.

Community
  • 1
  • 1
7stud
  • 46,922
  • 14
  • 101
  • 127
  • "every controller associated with that window" - How do you 'associate' NSObjectControllers with a window? – Gannet Mar 07 '21 at 04:40