Question about binding


#1

Hi there. Very fresh Obj-C/Cocoa n00b here. I’ve just finished reading the Objective-C book and I’m now on Cocoa Programming 4/E. Thanks for these very well written books! I’m from a web development background (front and backend), specifically Rails/jQuery, and these books have been very good at helping me with a few paradigm shifts.

Now for my question…

In Figure 8.4, the NSArrayController is bound to the RMDocument object. I re-read the parts about binding but I couldn’t really figure out why NSArrayController has to be bound to an intermediate object such as RMDocument. Is it just to follow the MVC convention? Or is it perfectly legal to just bind the Array Controller directly to an NSMutableArray?


#2

Glad you have found the books to be helpful!

In a manner of speaking the array controller is bound to the mutable array. It’s just that it has to go through RMDocument to get there. :slight_smile: There is very little difference between that and actually binding directly to the array. The reason that it can’t be bound directly to the array is simply because the array doesn’t exist as a top level object in the XIB file.

Technically you can create an instance of NSMutableArray in the XIB file and then bind directly to it from the array controller, but please never do this. :slight_smile: It doesn’t necessarily fly in the face of MVC, since your UI object (table view) would be connected to the model (mutable array) via a controller (array controller), but it would be pretty goofy.

In a document-based application it makes much more sense for the document to be managing the model objects that are within the document. For this reason it makes sense that we bind via the document, which is itself a kind of controller. In many cases controllers communicate with other controllers.

Adam


#3

Thanks for the reply and the tips, Adam! I also read in the first chapter of Cocoa Design Patterns that in the Cocoa framework, the C in MVC tends to be further split into two types of controllers: View Controllers and Model Controllers. This also helped me understand the reason for the design in Fig 8.4.