- Inherits from:
- NSObject
- Conforms to:
- NSObject
- (NSObject)
Declared in:
- AppKit/NSDocument.h
NSDocument. is an abstract class that defines the interface for documents, objects that can internally represent data displayed in windows and that can read data from and write data to files. Documents create and manage one or more window controllers, and are in turn managed by a document controller. Documents respond to first-responder action messages to save, revert, and print their data.
- init | Designated initializer for new documents. |
- initWithContentsOfFile:ofType: | For existing documents |
- dataRepresentationOfType: | Returns the document's data in a specified type. |
- loadDataRepresentation:ofType: | Loads data of a certain type into the document. |
- writeToFile:ofType: | Writes the document's data to a file. |
- readFromFile:ofType: | Reads the document's data from a file. |
- windowNibName | Returns the name of the document's sole nib file (resulting in the creation of a window controller for the window in that file). |
- makeWindowControllers | Creates and returns the window controllers used to manage document windows. |
NSDocument is an abstract class that defines the interface for documents. In a functional sense, a document is a repeatable container for a unique body of information identified by a name under which it is stored. In the context of the Application Kit, a document is an instance of an NSDocument subclass that knows how to represent internally, in one or more formats, the persistent data displayed in windows. A document can read that data from files and write it to files. It is also the first-responder target for many menu commands related to documents, such as Save Document, Revert Document, and Print Document. (When going up the responder chain, the Application Kit queries a window's NSDocument, if it exists, just after it queries the window delegate, if that is different from the NSDocument.) A document manages its window's edited status and is set up to perform undo and redo operations. When a window is closing, the document is asked before the window delegate to approve the closing.
To create a useful NSDocument subclass you must override some primitive methods and might want to override others. The NSDocument class itself knows how to handle document data as undifferentiated "lumps"; although it understands that these lumps are typed, it knows nothing about particular types. In their overrides of the data-based primitive methods, subclasses must add the knowledge of particular types and how data of the document's native type is structured internally and represented in document windows. Subclasses are also responsible for the creation of the window controllers that manage document windows, and for the implementation of undo and redo. NSDocument takes care of much of the rest, including running Open and Save panels, and generally managing the state of the document. See " "Creating a Subclass of NSDocument" " for more on creating subclasses of NSDocument, particularly the required and optional overridden primitive methods.
NSDocument is one of the triad of Application Kit classes that establish an architectural basis for document-based applications (the others being NSDocumentController and NSWindowController). Read the following section, "Document-Based Application Architecture" , for the concepts behind this architecture. Following that, "Implementing a Document-Based Application" gives the procedure for implementing it.
A document-based application is one of the more common types of applications developed today. They provide a framework for generating identically contained but uniquely composed sets of data that can be stored in files. Word processors and spreadsheet applications are two well-known examples of document-based applications. Before investigating how document-based applications are structured, let's consider exactly what such an application does. It:
Three Application Kit classes provide an architecture for document-based application that simplifies the work developers have to do to implement the features listed above. These classes are NSDocumentController, NSDocument, and NSWindowController.
Objects of these classes divide and orchestrate the work of creating, saving, opening, and managing the documents of an application. They are in tiered one-to-many relationship, as depicted in Figure 0-7. An application can have only one NSDocumentController, which creates and manages potentially many NSDocument objects (one for each New or Open operation). In turn, an NSDocument object creates and manages one or more NSWindowController objects, one for each of the windows displayed for a document. In addition, some of these objects have responsibilities analogous to NSApplication and NSWindow delegates.
Relationships between NSDocument, NSDocumentController, and NSWindowController
How do these objects divide the work among themselves? The place to start this discussion is not with any of the classes, but with a property list that specifies important details about the application's documents.
Each document-based application must include an NSTypes property in its custom info property list (CustomInfo.plist). This property specifies information about data types supported by its documents. When the NSDocumentController object creates a new document or opens an existing document, it searches this property list for such items as document class, file extension, whether the type is native or external, and whether external types can be only read or written.
Developers must hand-craft this property list for the current release. In future releases, Project Builder will assist in the creation of this property list.
The following code shows a sample CustomInfo.plist; the NSType property is the part specific to documents:
{ NSInfoPlistVersion = "5.0"; NSAppVersion = "1.0"; NSHumanReadableShortName = "SimpleTextEdit"; NSHumanReadableCompleteName = "Simple Text Edit Sample"; NSHumanReadableCopyright = "Copyright (c) 2000, Apple Computer, Inc."; NSTypes = ( { NSName = "rtf"; NSHumanReadableName = "RTF Document"; NSUnixExtensions = ("rtf"); NSDOSExtensions = ("rtf"); NSRole = Editor; NSDocumentClass = Document; } ); }
This property list tells the NSDocumentController for the SimpleTextEdit application that the application has one native type ("rtf"), meaning a type of document that, in its role as Editor, it can read and write. The human-readable type name is shown in a pop-up list in the Save Panel's accessory view (but only if there are multiple types). The extensions are used to filter the files shown in Open and Save panels; the first extension in each list is automatically added to file names specified in the Save panel. Most important is the document class; NSDocumentController uses this to create an instance of the NSDocument subclass appropriate to a data type. You never have to allocate and initialize your NSDocument explicitly in your code; it is done for you.
NSType is a dictionary with key/value pairs defined as follows:
NSName
NSHumanReadableName
NSIcon
NSMacOSTypes
NSMIMETypes
NSRole
NSDocumentClass
The primary job of an application's NSDocumentController object is to create and open documents, and to track and manage these documents. When a user chooses New from the File menu, an NSDocumentController gets the appropriate NSDocument subclass from the NSTypes property, allocates an instance of this class, and initializes this instance by invoking NSDocument's init method. When the user chooses Open from the File menu, NSDocumentController displays the Open panel, gets the user's selection, finds the NSDocument subclass for the file (based on its extension), allocates an instance of this class, and initializes the object and loads document data by invoking NSDocument's initWithContentsOfFile:ofType:. In both cases, the NSDocumentController adds a reference to the document object to an internal list to facilitate the management of its documents. It has a notion of the current document as the document whose window is currently key.
NSDocumentController is hard-wired to respond appropriately to certain application events, such as when the application starts up, when it terminates, when the system powers off, and when documents are opened or printed from the Workspace. If you wish, you can make a custom object the application delegate and implement the delegate methods invoked as a result of the same events, and these methods will be invoked instead. However, the default NSDocumentController object is an adequate application controller for most situations, and you should not need to subclass it. If you require additional behavior, such as displaying About panels and handling application preferences, it is recommended that a custom controller object perform these duties rather than a subclass of NSDocumentController.
The primary job of an NSDocument object is to represent, manipulate, store, and load the persistent data associated with a document. Based on the document types it claims to understand (as specified in the NSTypes property of the info property list), a document must be prepared to:
With the assistance of its window controllers, an NSDocument manages the display and capture of the data in its windows. By some special hard-wiring of the Application Kit, the NSDocument associated with the key window is the recipient of first-responder action messages when users save, print, revert, and close documents. In response to the appropriate action, it knows how to run and manage the Save panel and the Page Layout panel.
A fully implemented NSDocument knows how to track its edited status, print document data, and perform undo and redo operations. Although these behaviors aren't completely provided by default, NSDocument does assist the developer in implementing each. For edited-status tracking, NSDocument provides API for updating a change counter. For undo/redo operations, NSDocument by default lazily creates an NSUndoManager when one is requested, responds appropriately to Undo and Redo menu commands, and updates the change counter when undo and redo operations are performed. For printing, NSDocument facilitates the display of the Page Layout panel and the subsequent modification of the NSPrintInfo object used in printing.
Every application that takes advantage of the Application Kit's architecture for document-based applications must create at least one subclass of NSDocument. This architecture requires that you override some NSDocument methods in an either/or scenario, and recommends overriding several others in certain situations.
super
's
implementation. For more information on menu item validation, see
the description of the NSMenuValidation informal protocol.The initializers of NSDocument are another issue for subclassers.
The init method is the primary initializer, and it is invoked by
the other initializer initWithContentsOfURL:ofType:. The init method is
directly invoked when a new document is created; the initWithContentsOfFile:ofType: method
is directly invoked when a document is opened. Therefore if you
have any initializations that apply only to documents that are opened,
you should override initWithContentsOfFile:ofType:;
if you have general initializations, you should, of course, override init.
In both cases, be sure to invoke super
's implementation
as the first thing.
An NSWindowController manages one window associated with a document, which is usually stored in a nib file. If a document had multiple windows, each window would have its own window controller. For example, a document might have a main data-entry window and a window listing records for selection; each window would have its own NSWindow Controller. When requested by its owning NSDocument, an NSWindowController loads the nib file containing a window and displays it. It also assumes responsibility for properly closing windows (after ensuring that they are saved).
The NSWindowController offers additional behavior to document-based applications. It can store the size and location of windows in the user defaults database (this may not be desired behavior for most document-based applications, because it could quickly overpopulate the defaults database with document window-frame entries). It also cascades document windows in relation to each other, so they don't completely obstruct one another.
Subclasses of NSWindowController are optional. Applications can often use the default instance. Subclasses can augment NSWindowControllers to perform different nib-loading and setup tasks or to customize the titles of windows.
It is possible to put together a document-based application without having to write much code. If your requirements are minimal, the Application Kit provides you with a default NSWindowController instance and a default NSDocumentController instance. You just have to create a document project, compose the human interface, implement a subclass of NSDocument, and add any other custom classes or behavior required by your application.
The following procedures step you through the tasks you must do, and might want to do, when implementing a document-based application. Where something is described in detail elsewhere, such as overridden methods in NSDocument subclasses, you are referred there.
As for the three classes behind document-based applications, two likely concerns are the number of required objects and whether subclassing is necessary. The following table summarizes this information:
Class | How Many Objects? | Subclass? |
NSDocumentController | 1 per application | Optional (but unlikely) |
NSDocument | 1 per saved file | Required |
NSWindowController | 1 per document nib file | Optional (but likely) |
The Cocoa development environment provides a Document-Based Application project type to expedite the development of these kinds of applications. This project type provides the following things:
Document.h
and Document.m
,
which are derived from the definition of the NSDocument subclass
in the document nib file. The latter file includes empty but commented blocks
for the dataRepresentationOfType:, loadDataRepresentation:ofType:,
and windowControllerDidLoadNib: methods.
It also includes a fully implemented windowNibName method.The following procedure describes what you must do to create a document-based application when you use the project type developed for it. If this project type is absent on your system, you will have to complete the tasks listed above yourself. For this eventuality, the following table lists the appropriate first-responder action connections to make (that is, in Interface Builder connect the menu command to the "1" icon in the nib file window):
File Menu Command | First-Responder Action |
New | newDocument: |
Open | openDocument: |
Save | saveDocument: |
Save As | saveDocumentAs: |
Save To | saveDocumentTo: |
Save All | saveAllDocuments: |
Close | close |
Revert | revertDocumentToSaved: |
printDocument: | |
Page Layout | runPageLayout: |
Also, if you have added Undo and Redo menu items in the Edit menu, connect them to the first-responder undo: and redo: methods.
Do not generate an instance of Document to make these connections.
If you want your NSDocument subclass named something other than "Document," change the name in Interface Builder and wherever it occurs in the Document header and implementation (.m) files.The following procedure just gives general guidelines. For details see the complete NSDocument specification and especially "Creating a Subclass of NSDocument" . You might also want to read the class specifications of NSUndoManager, NSPasteboard, and the print classes.
// ----------------------------------------------------------------------------- - (NSData *)dataRepresentationOfType:(NSString *)aType { NSAssert([aType isEqualToString:@"rtf"], @"Unknown type"); return [textView RTFFromRange:NSMakeRange(0, [[textView textStorage] length])]; } // ----------------------------------------------------------------------------- - (BOOL)loadDataRepresentation:(NSData *)data ofType:(NSString *)aType { NSAssert([aType isEqualToString:@"rtf"], @"Unknown type"); fileContents = [data copyWithZone:[self zone]]; return YES; }
// ----------------------------------------------------------------------------- - (BOOL)writeToFile:(NSString *)fileName ofType:(NSString *)type { return [[textView string] writeToFile:fileName atomically:YES]; } // ----------------------------------------------------------------------------- - (BOOL)readFromFile:(NSString *)fileName ofType:(NSString *)type { fileContents = [[NSString alloc] initWithContentsOfFile:fileName]; return fileContents != nil; }
- (NSString *)windowNibName { return @"Document"; }
- (void)windowControllerDidLoadWindowNib:(NSWindowController *)windowController { [super windowControllerDidLoadWindowNib:windowController]; [textView setAllowsUndo:YES]; if (fileContents != nil) { [textView setString:fileContents]; [fileContents release];// Don't need it anymore fileContents = nil; } }
NSChangeDone
to set
the "dirty" flag.And of course, you implement any methods that are special to your NSDocument subclass.
If the default NSWindowController instance provided by the application kit does not meet the needs of your document-based application, you can create a custom subclass of it. If you do so, you must override NSDocument's makeWindowControllers to instantiate this custom class and add the created object to the document's list of window controllers.
If the default NSDocumentController object somehow does not meet all of your requirements for an application controller, such as handling user preferences or responding to uncommon application delegate messages, you should create a separate controller object (instead of subclassing NSDocumentController). For information on implementing NSDocumentController and NSWindowController subclasses, refer to the appropriate class specifications.
- Initializing an NSDocument
- - init
- - initWithContentsOfFile:ofType:
- - initWithContentsOfURL:ofType:
- Loading and representing document data
- - dataRepresentationOfType:
- - loadDataRepresentation:ofType:
- - fileWrapperRepresentationOfType:
- - loadFileWrapperRepresentation:ofType:
- Creating and managing window controllers
- - makeWindowControllers
- - windowNibName
- - windowControllerDidLoadNib:
- - windowControllerWillLoadNib:
- - windowControllers
- - addWindowController:
- - removeWindowController:
- - shouldCloseWindowController:
- Showing document windows
- - showWindows
- - displayName
- - setWindow:
- Reading from and writing to files
- - readFromFile:ofType:
- - writeToFile:ofType:
- - fileName
- - fileNameFromRunningSavePanelForSaveOperation:
- - setFileName:
- - runModalSavePanel:withAccessoryView:
- - shouldRunSavePanelWithAccessoryView
- - keepBackupFile
- - writeWithBackupToFile:ofType:saveOperation:
- Reading from and writing to URLs
- - readFromURL:ofType:
- - revertToSavedFromURL:ofType:
- - writeToURL:ofType:
- Managing document edited status
- - isDocumentEdited
- - updateChangeCount:
- Responding to user actions
- - printDocument:
- - runPageLayout:
- - revertDocumentToSaved:
- - saveDocument:
- - saveDocumentAs:
- - saveDocumentTo:
- Closing documents
- - canCloseDocument
- - close
- Reverting documents
- - revertToSavedFromFile:ofType:
- Printing documents
- - printShowingPrintPanel:
- - printInfo
- - setPrintInfo:
- - runModalPageLayoutWithPrintInfo:
- - shouldChangePrintInfo:
- Managing file types
- - setFileType:
- - fileType
- - fileTypeFromLastRunSavePanel
- + isNativeType:
- + readableTypes
- + writableTypes
- Managing menu commands
- - validateMenuItem:
+ (BOOL)isNativeType:(NSString
*)aType
See Also: + readableTypes , + writableTypes
+ (NSArray *)readableTypes
See Also: + isNativeType:, + writableTypes
+ (NSArray *)writableTypes
See Also: + isNativeType:, + readableTypes
- (void)addWindowController:(NSWindowController
*)aController
See Also: - setDocument: (NSWindowController)
- (BOOL)canCloseDocument
See Also: - close, - saveDocument:, - shouldCloseWindowController:
- (void)close
See Also: - canCloseDocument, - shouldCloseWindowController:
- (NSData *)dataRepresentationOfType:(NSString
*)aType
Here is a typical implementation:
- (NSData *)dataRepresentationOfType:(NSString *)aType { NSAssert([aType isEqualToString:@"rtf"], @"Unknown type"); return [textView RTFFromRange:NSMakeRange(0, [[textView textStorage] length])]; }
See Also: - loadDataRepresentation:ofType:
- (NSString *)displayName
MyDocument
"
if the path is "/tmp/MyDocument.rtf
").
If the document is new, NSDocument makes the display name "Untitled-n"
where n is a number in a sequence of new and unsaved documents.
Subclasses of NSWindowController can override windowTitleForDocumentDisplayName: to
modify the display name as it appears in window titles.- (NSString *)fileName
See Also: - fileNameFromRunningSavePanelForSaveOperation:, - setFileName:
- (NSString *)fileNameFromRunningSavePanelForSaveOperation:(NSSaveOperationType)saveOperation
NSSaveOperation
or NSSaveAsOperation
,
the accessory pop-up list contains only those document types the
application can read and write. If saveOperation is NSSaveToOperation
,
the pop-up lists additionally includes the document types that the
application can write (but can't read). If there is only one type
the document can be written to, or if shouldRunSavePanelWithAccessoryView returns NO,
the accessory view isn't shown. The default extension for saved
documents is the first extension assigned for the document's native
type or, if there is no native type, the extension for the first
writable type specified in the NSTypes property. File packages are
treated as files.See Also: - fileName, - runModalSavePanel:withAccessoryView:
- (NSString *)fileType
CustomInfo.plist)
.See Also: - setFileType:
- (NSString *)fileTypeFromLastRunSavePanel
- (NSFileWrapper *)fileWrapperRepresentationOfType:(NSString
*)aType
See Also: - loadFileWrapperRepresentation:ofType:
- (BOOL)hasUndoManager
See Also: - setHasUndoManager:
- (id)init
- (id)initWithContentsOfFile:(NSString
*)fileName
ofType:(NSString *)docType
nil
. In
opening the file, invokes the readFromFile:ofType: method. If it
successfully opens the file, it "remembers" fileName and docType (through setFileName: and setFileType:). This initializer
is typically invoked by NSDocumentController's makeDocumentWithContentsOfFile:ofType:.- (id)initWithContentsOfURL:(NSURL
*)anURL
ofType:(NSString *)docType
nil
. In
opening the location, invokes the readFromURL:ofType: method. If it
successfully opens the file, it "remembers" anURL and docType .
This initializer is typically invoked by NSDocumentController's makeDocumentWithContentsOfURL:ofType:.- (BOOL)isDocumentEdited
See Also: - updateChangeCount:, - setDocumentEdited: (NSWindow)
- (BOOL)keepBackupFile
See Also: - writeToFile:ofType:
- (BOOL)loadDataRepresentation:(NSData
*)docData
ofType:(NSString *)docType
Here is an example implementation:
- (BOOL)loadDataRepresentation:(NSData *)data ofType:(NSString *)aType { NSAssert([aType isEqualToString:@"rtf"], @"Unknown type"); fileContents = [data copyWithZone:[self zone]]; return YES; }
See Also: - dataRepresentationOfType:
- (BOOL)loadFileWrapperRepresentation:(NSFileWrapper
*)wrapper
ofType:(NSString *)docType
See Also: - fileWrapperRepresentationOfType:
- (NSArray *)makeWindowControllers
If subclasses do not override this method, they must override windowNibName, but they should do so only if the following two conditions apply:
If you override this method, windowControllerDidLoadNib: and windowControllerWillLoadNib: are invoked, as they are when windowNibName is implemented.
The default
implementation raises NSInternalInconsistencyException and returns nil
.
See Also: - windowControllers
- (void)printDocument:(id)sender
See Also: - printInfo, - runPageLayout:, - setPrintInfo:, - shouldChangePrintInfo:
- (NSPrintInfo *)printInfo
See Also: - runPageLayout:, - setPrintInfo:, - shouldChangePrintInfo:
- (void)printShowingPrintPanel:(BOOL)flag
See Also: - printInfo
- (BOOL)readFromFile:(NSString
*)fileName
ofType:(NSString *)docType
This method is one of the location-based primitives. Subclasses can override this method instead of overriding loadDataRepresentation:ofType: to read and load document data. Subclasses that handle file packages such as RTFD or that treat locations of files as anything other than paths should override this method. Override implementations of this method can filter the document data using NSPasteboard's or other filtering services.
See Also: - dataRepresentationOfType:, - writeToFile:ofType:
- (BOOL)readFromURL:(NSURL
*)anURL
ofType:(NSString *)docType
- (void)removeWindowController:(NSWindowController
*)windowController
- (IBAction)revertDocumentToSaved:(id)sender
See Also: - updateChangeCount:
- (BOOL)revertToSavedFromFile:(NSString
*)fileName
ofType:(NSString *)type
See Also: - revertDocumentToSaved:
- (BOOL)revertToSavedFromURL:(NSURL
*)anURL
ofType:(NSString *)type
See Also: - revertDocumentToSaved:
- (int)runModalPageLayoutWithPrintInfo:(NSPrintInfo
*)printInfo
See Also: - shouldChangePrintInfo:, - runModalWithPrintInfo: (NSPageLayout)
- (int)runModalSavePanel:(NSSavePanel
*)savePanel
withAccessoryView:(NSView *)accessoryView
See Also: - shouldRunSavePanelWithAccessoryView
- (IBAction)runPageLayout:(id)sender
See Also: - setPrintInfo:, - updateChangeCount:
- (IBAction)saveDocument:(id)sender
See Also: - fileNameFromRunningSavePanelForSaveOperation:, - setFileName:, - setFileType:, - updateChangeCount:
- (IBAction)saveDocumentAs:(id)sender
See Also: - fileNameFromRunningSavePanelForSaveOperation:, - setFileName:, - setFileType:, - updateChangeCount:
- (IBAction)saveDocumentTo:(id)sender
See Also: - fileNameFromRunningSavePanelForSaveOperation:
- (void)setFileName:(NSString
*)fileName
See Also: - fileName
- (void)setFileType:(NSString
*)docType
See Also: - fileType
- (void)setHasUndoManager:(BOOL)flag
See Also: - hasUndoManager
- (void)setPrintInfo:(NSPrintInfo
*)printInfo
See Also: - printInfo
- (void)setUndoManager:(NSUndoManager
*)undoManager
nil
,
it turns off the hasUndoManager flag. If undoManager is non-nil
,
it adds the receiver as an observer of NSUndoManagerDidUndoChangeNotification, NSUndoManagerDidRedoChangeNotification,
and NSUndoManagerWillCloseUndoGroupNotification.See Also: - undoManager)
- (void)setWindow:(NSWindow
*)aWindow
- (BOOL)shouldChangePrintInfo:(NSPrintInfo
*)newPrintInfo
- (BOOL)shouldCloseWindowController:(NSWindowController
*)windowController
See Also: - close, - shouldCloseDocument (NSWindowController)
- (BOOL)shouldRunSavePanelWithAccessoryView
Here is an example implementation:
- (BOOL)shouldRunSavePanelWithAccessoryView { return [self fileName] == nil; }
See Also: - runModalSavePanel:withAccessoryView:
- (void)showWindows
- (NSUndoManager *)undoManager
nil
if the receiver
should not own one. If the undo manager doesn't
exist and hasUndoManager returns YES, it creates one and invokes setUndoManager: with
the NSUndoManager as argument.- (void)updateChangeCount:(NSDocumentChangeType)changeType
NSChangeDone
), decrement (NSChangeUndone
)
, or set to zero (NSChangeClear
)
the change count. If you are implementing undo and redo in an application,
you should increment the change count every time you create an undo
group, and decrement the change count when an undo or redo operation
is performed.Note that if you are using NSDocument's default undo/redo features, setting the document's edited status by updating the change count happens automatically. You only need to invoke this method when you are not using these features.
- (BOOL)validateMenuItem:(NSMenuItem
*)anItem
- (void)windowControllerDidLoadNib:(NSWindowController
*)windowController
See Also: - windowControllerWillLoadNib:, - windowControllers
- (void)windowControllerWillLoadNib:(NSWindowController
*)windowController
See Also: - windowControllerDidLoadNib:, - windowControllers
- (NSArray *)windowControllers
See Also: - makeWindowControllers, - windowControllerDidLoadNib:, - windowControllerWillLoadNib:, - windowNibName
- (NSString *)windowNibName
The default implementation returns nil.
See Also: - windowControllers
- (BOOL)writeToFile:(NSString
*)fileName
ofType:(NSString *)type
This method is one of the location-based primitives. Subclasses can override this method instead of overriding dataRepresentationOfType: to write document data to the file system as an NSData object after creating that object from internal data structures. Subclasses that handle file packages such as RTFD or that treat locations of files as anything other than paths should override this method. Override implementations of this method should ensure that they filter document data appropriately using NSPasteboard's filtering services.
See Also: - loadDataRepresentation:ofType:, - readFromFile:ofType:, - writeToFile:ofType:originalFile:saveOperation:
- (BOOL)writeToFile:(NSString
*)fileName
ofType:(NSString *)type
originalFile:(NSString *)origFileName
saveOperation:(NSSaveOperationType)saveOp
- (BOOL)writeToURL:(NSURL
*)anURL
ofType:(NSString *)type
- (BOOL)writeWithBackupToFile:(NSString
*)fileName
ofType:(NSString *)fileType
saveOperation:(NSSaveOperationType)saveOp