| < Previous PageNext Page > |
Many applications let users create and edit documents: unique aggregations of data presented in windows with identical user interfaces. Word processors, photo-image editors, and web browsers are examples of document-based applications. These applications have similar features. They enable users to create new documents, save those documents to files, and then open those documents later. Document-based applications also validate menu items, monitor each document's edited status, manage document windows, and respond appropriately to application-wide events (such as termination). Often they can have different internal representations of document data.
Cocoa offers developers an architecture that reduces the effort required to implement a document-based application with features such as these. The essential component of this architecture includes three Application Kit classes: NSDocument, NSDocumentController, and NSWindowController. In a document-based Cocoa application, objects of these three classes have distinct spheres of responsibility and a cascading series of relationships with each other based on ownership and management (Figure 7-1).
A Cocoa application that is based on the document architecture has a single NSDocumentController object. This object owns and manages one or more NSDocument objects. Each of these NSDocument objects, in turn, creates and manages one or more NSWindowController objects. And each NSWindowController object is associated with a window of the document. (A document can have multiple windows.) An NSWindowController object manages the presentation of the document.
Each of the three kinds of objects in the Cocoa document architecture has a specific responsibility which is dictated by its MVC role:
The NSDocumentController object manages the application's documents. It initiates and coordinates the creation of new documents, the saving of edited documents, and the opening of saved documents. It plays the MVC role of a coordinating controller for the entire application. The NSDocumentController object is provided automatically for document-based applications. You generally do not need to subclass it.
NSDocumentController gets the information it needs to manage documents from the document-type metadata specified in the application's information property list (Info.plist). This metadata tells the application the extensions, HFS type code, MIME types, icon, and NSDocument subclass (if applicable) of each document the application can read and write.
An NSDocument object manages the model objects of a document. In MVC terms, an NSDocument object is a model-controller, a controller whose management responsibility is shifted towards the model layer. NSDocument is an abstract class, and you must create a custom subclass of it that has knowledge of the document's data, as encapsulated in model objects. The instance of that subclass must be able to read data from a file and from it re-create the document's model objects, and it must be able to save the document's current collection of model objects to a file. Occasionally it may have to maintain more than one internal representation of document data. An NSDocument object also owns and manages one or more NSWindowController objects.
An NSWindowController object manages the presentation of the document in a window. In MVC terms, a NSWindowController document is a view-controller: Its concern is managing the window in which document data is displayed. For simple applications you might not need to create a custom subclass of NSWindowController; the default instance can handle rudimentary window-management chores while the NSDocument object can incorporate knowledge of the view layer. But in most cases you should add the knowledge of the document's view objects to an NSWindowController subclass. An instance of this subclass is typically the File's Owner of a document nib file. A multi-window document can have several different NSWindowController objects, one for each window.
Xcode provides a project template for Cocoa applications based on the document architecture. When you create a project using this template, you get an NSDocument subclass (named MyDocument) with stub implementations of the required method overrides. You also get a document nib file with File's Owner set to MyDocument.
Further Reading: For a complete description of the document architecture, see Document-Based Applications Overview.
| < Previous PageNext Page > |
© 2006 Apple Computer, Inc. All Rights Reserved. (Last updated: 2006-12-20)
|