Project-based NSDocument Workflow

Question

What is the best technique people have found for dealing with a project/parent-child relationship when using the NSDocument architecture?

My goal is to have a NSDocument manage a set of files on the filesystem (a non-opaque bundle, similar to Xcode project directories, not the project bundle) along with settings. The files on the filesystem should be their own NSDocument, but be able to reference the project NSDocument. Ideally this project NSDocument is able to display (in-Window) "child" NSDocuments of a defined type. In short, I want the editing interface of Xcode.

Am I approaching this incorrectly? Should I only be using a single NSDocument (the "document" of the project settings and the underlying plain files on the filesystem)?

Answer 1

There is no builtin way to define document relationships. I would suggest having one document class which uses custom window controllers to do most of it's work. You can have multiple document types all using the same class to determine which window should be active when a project is opened according to which file in the project was selected. Your NSDocument class would handle communication between the different window controllers, as well as loading/unloading different window controllers as needed. Each different type of file in the project would get it's own custom NSWindowController class, which would handle many of the duties usually handled by the document, such as file loading/saving, undo management, etc. Since the window controller comes before the document in the responder chain, you wouldn't have to worry about forwarding most of these events to the current window controller. Essentially, this is what you asked for, but you are using window controllers instead of child documents.