Article:		The Cocoa Controller Layer
Subject:		...And now?
Date:		2004-04-08 01:25:00
From:		isil
As already stated, that's a great article on a great technology. But it lacks a crucial (IMHO) point: how the collected dictionary of book objects can be accessed from the myDocument class? this closes the MVC loop, and allows us poor mortals to serialize the library down to a file...

Showing messages 1 through 3 of 3.

• ...And now?
  2004-04-15 05:54:05  ANegmAwad [View]
  
  
  As the pre-poster said, You can add a key to the binding of the controller, i.e.
  
  Stock
  NSString* Name;
  NSMutableArray* stuff;
  
  You add an ArrayController and bind it to Stock with the key stuff.
  
  There is no need for an IBOutlet.
  

• ...And now?
  2004-04-09 22:08:56  sanguish [View]
  
  
  You'd create an outlet for the Book array in the document class.
  
  (There isn't really any reason to make a custom class Book in this case, as I didn't see anything other than accessors for it.. you could easily use NSMutableDictionary instead
  
  
  you'd establish a binding from the array controller to the array key (on the File's Owner) rather than connecting it to the content outlet.
  
  Hmmr.. looking at the article, and the source, I don't see where he's connecting the array and the array controller.

• ...And now?
  2004-04-08 07:22:27  eblubeta [View]
  
  
  generally you put an Outlet in YourDocumentType to the controller.
  
  the generic controller keeps an instance var named "contentObject", which you can access by name:
  [myControllerobj contentObject]; (big part of KVC btw)
  
  what should follow in your brain is all of the cards falling into place for how to connect to any other data In any other objects in the controller layer.
  
  simply look it up in the new online Apple dev ref docs, and find the name of the offending data, then make "yourclass" aware of the controller in IB, and you can ask for any of its data.