How to implement a complex NSDocument-based application that imports and exports non-native file types?

Question

I am working on an application that supports a very complex set of operations. This looks like something like Xcode, as the main document is presented as something like a project window with many entries in it. A document on disk is a collection (this means a directory with the file structure and folder structure below it).

There is at least one type of file that it can import and export (.mfst), but is not intended to directly edit this type of file. That is, opening this type of file leads to the creation of its own type of document and the contents of the file imported into it. On disk, the file is a package (.mproj) with numerous files contained in it.

Technically, this file is copied verbatim to the right place inside your own package of documents. Any changes to the data contained in this file are saved in the copy in the kit, and not in the copy that was imported.

This type of file can also be exported.

Question 1: Is this application a viewer of an imported type or editor? I think this is the first.

Question 2: This support question for imported types shows how to implement import through a subclass of NSDocument, but it seems that subclassing NSDocumentController is possible is a good way to go.

One reason for this is that if the user has already imported the .mfst file, I want to catch this fact. There are other files that can be associated with an open document and should be imported into this document, and not create a new one.

Question 3: Unfortunately, some of the code for working on a project requires certain files on disk. This means that even when a new document is created in response to opening the type of the imported file, I need to continue and create the package on disk and copy the file there so that it can work. I would like to maintain the illusion of the user that this is a nameless, unsaved document. Is it possible?

I understand that this goes against Apple's “modern” concept of documents that do not need to be saved. Perhaps it would be best if all operations were automatically saved. I know that I never liked that I could not explicitly save the document. I'm not really sure what the recommended user interface is these days (Apple seems to have changed course on this).

Recommendations are welcome.

Answer 1

• The behavior sounds like viewing the source file because it cannot modify the file.

  For exported file types, add them to the Info.plist application Info.plist using the key value UTExportedTypeDeclarations . Below is an example from Font Pestle . Font Pestle does not open or edit CSS, but it exports the format:

    <key>UTExportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> <string>public.source-code</string> <string>public.utf8-plain-text</string> </array> <key>UTTypeDescription</key> <string>Cascading Style Sheet</string> <key>UTTypeIdentifier</key> <string>eu.miln.font-pestle.css</string> <key>UTTypeReferenceURL</key> <string>http://www.w3.org/Style/CSS/</string> <key>UTTypeTagSpecification</key> <dict> <key>public.filename-extension</key> <array> <string>css</string> </array> </dict> </dict> 

• The NSDocumentController subclass is a reasonable place to validate previously imported copies of an open file.

  If you find yourself writing hundreds of lines of code in your subclass of NSDocumentController , change your design. Required subclass should be minimal.

• Use NSDocument support for NSFileWrapper .

  NSFileWrapper designed to facilitate package-based document management. NSDocument and NSFileWrapper will handle saving temporary copies of your document that are not registered before the user actively saves or must choose a destination for the document.

I highly recommend reading Apple About Cocoa Document Architecture and following its recommendations as close as possible. This will save you time and hopefully simplify your application as Apple develops its core frameworks.