Re: NSPersistentDocument and custom window controller
Re: NSPersistentDocument and custom window controller
- Subject: Re: NSPersistentDocument and custom window controller
- From: Quincey Morris <email@hidden>
- Date: Mon, 27 Jun 2011 16:17:06 -0700
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).
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden