Creating document based applications

Note: First version; subject to further revisions and changes. --ChrisArmstrong 07:09, 7 Jul 2005 (CEST)

Introduction

OpenStep supports document-based applications, simplifying the process of creating applications whose behaviour is familiar to many users. GNUstep also provides this functionality to the developer. This guide 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 interface files (often referred to as nibs), 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. When programming, classes that will be used as part of the AppKit are:

NSDocument

This class is central to the OpenStep document based model. These application's declare a new instance of a subclass of NSDocument for each “document” that is opened. You will 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 opening and creating documents at an application level).

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 responsible 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 instantiated 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. I believe it is also capable of providing support for document-based applications. 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

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.

I have provided an example for this file below. ProjectBuilder creates one as well. Please note that "TextEdit" 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 extension 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" );
    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 files

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 an "Application" template: Use a standard Gorm template for an Application.
• Delete the NSWindow instance: In the "Objects" pane, remove the NSWindow instance by going File->Delete (unless you need a main window, which is beyond the scope of this document).
• Set NSOwner's class to "NSDocumentController": This is the custom class option of NSOwner in the property inspector. This ensures that the openDocument:, newDocument: messages, as sent to NSFirst, get picked up by NSDocumentController. Do not instantiate it (I believe you can't anyway).
• [Optional] Subclass NSDocumentController: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 then set NSOwner to be of your custom subclass type.
• Add a "Document" menu: Drag a Document menu from the palette onto your main menu. This already has the proper outlet and action linkage for each relevant message to be directed to NSFirst. Generic messages (such as openDocument:, not associated with any document instance) 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.
• [Optional] Add other menus: Add any appropriate menus such as "Info" and "Format" which may be relevant to your application.

Document Interface File(s)

The document interface file is 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 document window. This interface file is instantiated every time a person creates a new document (the newDocument: message is sent 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. It is up to you whether or not you let Gorm generate the class files, but make sure you add the appropriate outlets to your class in the source files (otherwise, I think your your program may segfault).
• Set NSOwner: Set your subclass as NSOwner's Custom class 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 your 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 connect NSOwner to the appropriate controls/views, and select 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; 

/* The document type string, as specified in the property list NSTypes array */ 

NSString * GSTextDocumentType = "GSTextDocumentType";
@interface TextDocument : NSDocument
{
@protected
    /* Outlets we added in our Gorm nib file */
    id * textView;
    NSString* fileContents;
}
/* 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 tries 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 TRUE/YES).

For example, in terms of the TextEdit example:

- (BOOL) loadDataRepresentation:(NSData*) representation ofType:(NSString*)type
{
   /*Check type information */
   if (![type isEqual:GSTextDocumentType])
       return NO;
   /* Clean out our old representation if it still exists */
   if (self->fileContents) RELEASE(self->fileContents); 

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

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

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

If this is not sufficient, 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:. Again, see the GUI manual for more details.

dataRepresentationOfType: is used to save the data. Your method is expected to return an instance of NSData that contains what should be saved to a file, for the type specified. Again, the type variable should be checked to ensure that you can write data of that type. Return nil if the file cannot be saved as that type.

For example:

- (NSData*) dataRepresentationOfType:(NSString*)type
{
    if (![type isEqual:GSTextDocumentType])
        return nil; 

    NSData stringData =  [[textView string] dataUsingEncoding:NSASCIIStringEncoding];  
    return stringData; 
}

If a more sophisticated save implementation is needed, consult the documentation for information on the writeTo* methods.

windowNibName

This method must be overridden to return the a string of the name of your nib file (without the file extension). More complex implementations will use other methods to load the interface files. TODO: information on what methods need to be overridden.

windowControllerDidLoadNib:

Use this method to add code that should be run as soon as windowController has been initialised. Your document may have many window controllers; each window controller taking possession of one window.

In the TextEdit example, this method is used to copy the fileContents variable to the text view. It otherwise initialises the document window.

Also note that you can override windowControllerWillLoadNib: to perform pre-interface loading initialisation.

makeWindowControllers

This is an optional method to override, which must be used if you have multiple window controllers per document. It is responsible for creating each window controller from it's interface file and then adding it to the document. Use the addWindowController: method.

Other considerations

• You need a way to notify NSDocument that your document has changed, so that NSDocumentController can enable the menu item to allow saving. This is done by a call to the updateChangeCount: method. For example, the TextDocument class adds itself as a delegate to the textView, for any notification of changes. It then calls updateChangeCount: in the delegate's method.

• You may also wish to add a close: method (not the close method already in NSDocument, see below) to respond to the menu item permitting your document to close. This could perform cleanup operations before a call to [self close] is made e.g.

- (void) close:(id)sender /* Note this is not the method found in NSDocument (they differ by a parameter) */
{
    [self close];
}

NSDocumentController

This class can optionally be subclassed, to implement some specific functionality. For example, programs handling multiple document types may override newDocument: to create a window so that the user can select which document type to create.

You should use separate implementation files and add the .m file to GNUmakefile.

NSWindowController

This class can also be optionally subclassed, to implement functionality specific to a window controller for a document type. You may need to override makeWindowControllers: in the NSDocument subclass in order to make sure your specific window controller is instantiated.

You should use separate implementation files and add the .m file to GNUmakefile.

Optional Additions

Custom NSDocumentController and NSWindowController implementations

See NSWindowController and NSDocumentController.

---