Creating document based applications

Note: this is a work in progress. Please bear with me as I add further information. --ChrisArmstrong 08:33, 5 Jul 2005 (CEST)

Introduction

OpenStep can provide your application a document-based model. It helps to simplify the process of creating such applications. GNUstep is compatible with this paridgm as well; this document aims to provide an overview of what is required in the creation and design of such an application.

It is assumed you are familiar with GNUstep, and have some understanding as how to create Gorm's nib files, as well as some understanding of how they work.

Importantly, such applications have certain components that are required, and should be considered as part of their design. At a programmatic level, classes that will be used as part of the AppKit are:

NSDocument

This class is central to the OpenStep document based model. Such an application declares a new instance of a subclass of NSDocument for each “document” that is opened. It will be necessary to subclass NSDocument to implement this.

Each instance of your NSDocument subclass may have one or more windows associated with it. These are used as an interface for loading and saving a representation of your document type. Each window will have an “NSWindowController” instance associated with it, where NSDocument maintains a list of these.

NSDocumentController

This class acts a controller. It maintains a list of documents (instances of your NSDocument subclass) and is responsible for loading and instantiating new documents. It is usually not necessary to implement a subclass of this, but often it may be useful to implement special functionality (especially related to open documents as a whole).

NSWindowController

As mentioned above, NSWindowController instances are individually associated with one NSWindow instance, in such a way that a document maintains a list of window controllers that are reponsible for rendering the views associated with a document.

You will most likely not have to subclass NSWindowController. Instead, you associate a nib file (the Gorm output) with the subclass of NSDocument, and NSDocumentController will load this nib file for each document that is created or loaded.

For example, a text based application that is used for the editing of plain text files, may subclass NSDocument with a TextDocument class. Each instance of this class would have an NSWindowController instance associated with it, which in turn manages a window instance that is instantiated from a nib file. The NSDocumentController instance, as managed and instatiated by GNUstep, would be responsible for loading and saving documents in your application. It even prompts the user to save their documents when they try to quit the application.

File Components

In building your application you will need to create a number of special files. From scratch, the following should be a rough guide to getting it working. These include the Makefile, your application's property list and the interface files.

The Makefile

For this type of application, no special makefile is needed: it just has to be a normal application. Project Builder should be able to spit out the required makefile and Gorm files that are needed for a generic application. Otherwise use the following as a template:

GNUmakefile

include $(GNUSTEP_MAKEFILES)/common.make


APP_NAME = DocumentApp

DocumentApp_OBJC_FILES =

 MyDocument.m 

 main.m


DocumentApp_RESOURCES = \ 

 Resources/Info-gnustep.plist \

 Resources/DocumentApp.gorm \

 Resources/MyDocument.gorm


-include GNUmakefile.preamble

include $(GNUSTEP_MAKEFILES)/application.make

-include GNUmakefile.postamble

For more information as to customising this file, as well as setting up compiler options for third party libraries and includes, see the GNUstep makefile manual.

The application dictionary - Info-gnustep.plist

For those that have edited this file in their project before, it is a dictionary with various values entered. For our purposes, we need an array within the main dictionary, called "NSTypes". This is a array of unnamed dictionaries, with one dictionary for each type.

An entire example of this file, for a "theoretical" TextEdit application (please note that such an application does exist as an example application from Next I think, and again on MacOS X but I have constructed a much simpler version, used only for plain text files).

Taking a look at the single dictionary entry in the NSTypes array, the following key-value pairs are needed:

• NSDocumentClass: This is (string) the subclass name you use in your code, the "objective-c name" of your document subclass. This is used by NSDocumentController's default implementation to create instances of your document type.
• NSName: The generic file type (string). This is completely arbitrary, and can be anything you like. For the purpose of conventions, it may be more appropriate not to use the "NS" or "GS" prefix (the latter of which I not sure), and instead use either your own, or no prefix at all.
• NSHumanReadableName: The human readable name of your document type (string)? TODO: explain where this is used.
• NSUnixExtensions: An array of strings, each containing a file extension connected to this document type on "unix" platforms. TODO: explain how "unix" is interpreted by GNUstep.
• NSDOSExtensions: An array of strings, each containing a file extenstion connected to this document type on "DOS" platforms (could be loosely interpreted as any MS platforms GNUstep runs on, i.e. Windows 2000/XP).
• NSRole: A string, either "Viewer" or "Editor", depending on how your document operates on this file type.
• NSIcon: A icon name associated with this document type. TODO: Investigate how this works.

Info-gnustep.plist

{
    ApplicationDescription = "A simple text editor for GNUstep.";
    ApplicationName = TextEdit;
    ApplicationRelease = 0.10;
    Authors = ( "Christopher Armstrong <quineska@gamebox.net" );
    Copyright = "Copyright (C) 2005 Christopher Armstrong";
    CopyrightDescription = "Released under GPL.";
    FullVersionID = 0.10;
    NSExecutable = TextEdit;
    NSMainNibFile = TextEdit.gorm;
    NSPrincipalClass = NSApplication;
    NSRole = Application;
    NSTypes = (
        {
                NSDocumentClass = "TextDocument";
                NSName = "GSTextDocumentType";
                NSHumanReadableName = "Text Document";
                NSUnixExtensions = ( "txt", "" );
                NSDOSExtensions = ( "txt" );
                NSRole = Editor;
        }
    );
}

For more information on property list files, consult Property Lists.

Interface file

Two interface files are needed: one for your main application, and another that will be instantiated with each instance of your document subclass. These both should be listed as resources in your makefile, (as shown the GNUmakefile example above). It may be helpful to name the document nib file after your class.

Application Interface File

The application one should just be a menu (though it could be more if necessary). When constructing it, take the following into account:

• Use a standard Gorm template for an Application.
• Delete the window instance in the "Objects" pane (unless you need a main window, in which case I don't know how to operate).
• Set NSOwner's class to "NSDocumentController" (this is the custom class option of NSOwner in the property inspector). This ensures openDocument, newDocument, etc. messages, as sent to NSFirst, get picked up by NSDocumentController. Do not instantiate it (I believe you can't anyway).
• If you intend to subclass NSDocumentController, subclass it in the Classes pane. To make sure that this class is instantiated and used, make sure you instantiate it in Gorm or in your main.m file, and set NSOwner to be your subclass.
• Drag a Document menu from the palette onto your main menu. This already has the proper linkage for each relevant message for a document setup to be directed to NSFirst. In the case of generic messages (such as openDocument:, not associated with any document instance), these are forwarded to the shared instance of NSDocumentController (see it's reference documentation). When a document is active, more specific messages (such as close: or saveDocument:) are forwarded to the relevant document instance of your NSDocument subclass.
• Add any appropriate menus such as "Info" and "Format" which may be relevant to your application.

Document Interface File

The document interface file is (generically) a window containing the view(s) required for the implementation of one instance of your document type. For example, in the case of a TextDocument type, a window instance with a NSTextView drawn on it is used for each open window. This nib file is instantiated every time a person creates a new document (the newDocument: message goes to NSDocumentController) or opens an existing document (openDocument:).

You will need to:

• Subclass NSDocument with your document type in Gorm (this is done in a couple of ways, see custom classes).
• Set NSOwner: Set your subclass as NSOwner's Custom class (done using the Property inspector). DO NOT INSTANTIATE IT.

Another thing that you may want to consider is custom outlets. If you place certain views or controls on your window (including the window itself), you may want to refer to them directly in yout code, e.g. the NSTextView in our TextEdit example is accessed directly, so that we can save it's contents to a file. To enable this, we add outlets to our class (see custom classes). We then connected NSOwner to the appropriate controls/views, and selected the outlets in the Connections property inspector (see editing the interface).

Code

Various things need to be done at a code level, to ensure that your NSDocument subclass is properly instantiated. This section aims to tell you what is necessary.

NSDocument subclass

When creating your subclass, you may have chosen to have Gorm create the class files. If not, you should create two files for your subclass: a header (.h) file and an implementation file (.m). The header file should take the following layout (we're using the TextEdit example again):

#ifndef TEXTDOCUMENT_H
#define TEXTDOCUMENT_H 

#include <AppKit/AppKit.h> 

@class NSDocument; 

@interface TextDocument : NSDocument
{
@protected
    /* Outlets we added in our Gorm nib file */
    id * textView;
}
/* Basic methods used for loading and saving document data (respectively). */
- (BOOL) loadDataRepresentation:(NSData*)representation ofType:(NSString*)type;
- (NSData*) dataRepresentationOfType: (NSString*)type; 

/* Information and events handling of GUI related changes */
- (NSString*) windowNibName;
- (void) windowControllerDidLoadNib:(NSWindowController*)windowController; 

@end

Firstly, take note that we inherit from NSDocument. As a result, we need to override some methods for a basic (but working) implementation.

loadDataRepresentation:ofType: and dataRepresentationOfType:

The methods, loadDataRepresent:ofType: and dataRepresentationOfType: are used by NSDocumentController to load and save our files. The first method is called when the user trys to open a document (NSDocumentController gets the file name and copies it's data using an open panel). The method is passed the raw data in this file, as well as a string representing its type. It is important to note that this type string is the same one used in your property list. It is used by NSDocumentController to tell you what type it thinks you should open the data with. If this is not possible, or if there is an error trying to parse the data, your method returns FALSE/NO. Otherwise, you should store a local, meaningful representation of the data, which you can insert into your document window a little later (and return YES).

For example, in terms of the TextEdit example:

- (BOOL) loadDataRepresentation:(NSData*) representation ofType:(NSString*)type
{
   /* Clean out our old representation if it still exists */
   if (fileContents) RELEASE(fileContents); 

   /* Allocate room for the new data, and try to initialise a string with it. */
   self->fileContents = [NSString alloc];
   fileContents = [fileContents initWithBytes: [representation bytes]
                        length: [representation length]
                      encoding: NSASCIIStringEncoding]; 

   /* If this can't be done, return NO */
   if (!fileContents)
       return NO; 

   /* Otherwise, set our TextView to the string data. */
   [self->textView setString: fileContents];
   return YES;
}

If this is not suffice, or if your program can open the data in a more efficient manner, it may be worth looking into overriding -initWithContentsOfFile:ofType: and -initWithContentsOfURL:ofType: (see the GUI manual for more details).

windowNibName

This method must be overriden to return the name of your nib files. More complex implementations will use other methods to load the interface files. TODO: information on what methods need to be overriden.