On Jun 27, 2011, at 6:17 PM, Quincey Morris wrote: > On Jun 27, 2011, at 15:58, Philip Dow wrote: > >> I am exploring using a custom window controller for a core data document >> based application and wanted to ask those more knowledgeable than myself if >> there are any caveats I must consider. >> >> Following the documentation, I am overriding NSDocument's >> makeWindowControllers method in my NSPersistentDocument subclass and am >> initializing the window controller here before calling addWindowController. >> Everything works as expected in a simple trial run. >> >> The critical difference is that I am not using my document subclass as the >> window controller's owner, and neither will my document subclass be the >> window's delegate. I am pursuing this route because the custom window >> controller is based on existing code which I am integrating into my >> application and which requires that the window controller itself be the nib >> owner and window delegate. >> >> My concern is that I will lose some built-in essential functionality if the >> persistent document assumes that it is the owner of the nib file and the >> window delegate. I don't know that it does, which is why I'm checking here. >> An example is the undo functionality which is normally provided by the >> managed object context in a persistent document. >> >> Does the persistent document framework make any assumptions about the >> persistent document normally owning its nib file and acting as its window >> delegate which I must make up for when using a custom window controller that >> takes over these two roles? > > Nope, what you're proposing is perfectly normal. It's within NSDocument's > intended behavior that a NSWindowController should take over the role of > being the window nib's File's Owner. All you need to do is have your > NSWindowContoller subclass' init method use [super initWithNibName:] -- or, > what is the same thing, [super initWithNibName: ... owner: self] -- and > NSDocument bows out of the nib picture. > > The fact that it's really a NSPersistentDocument isn't important. This part > of the behavior comes directly from NSDocument. Undo (in the sense of its > relationship to Core Data) is a data model function, so it doesn't care what > kind of controller sits between the data model and the user interface. > > The only factor I can think of to consider is that the Core Data model and > managed context come from the document. However, addWindowController: sets > the window controller's "document" property to the document object, so you > can always get to document-based information via windowController.document > (once nib loading reaches the awakeFromNib point, that is).
Fantastic. Yes, I did discover that I needed a way to pass the managed context to other objects such as view controllers which might require it in their turn. The code I'm integrating uses other objects in the control layer alongside the window controller to create the view controllers which manage the window content -- it is a tabs system based on the Chrome code -- and I've subclassed that class to pass the managed object context around. It works nicely. ~Phil_______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
