4

I am writing a Mac Cocoa application that will manipulate database files, which can be easily be implemented using NSDocument technology, as they relate directly to disk files.

However the majority of the app will manipulate items within this database. When user opens a database item, a new Window should appear to allow the item to be viewed, edited, saved, so the database item doesn't directly relate to a disk file. Note that undo and redo is appropriate here.

Is it appropriate to use NSDocument technology for both database windows and database item windows, or is there a better approach?

trojanfoe
  • 120,358
  • 21
  • 212
  • 242

2 Answers2

3

I think using NSDocument would be a great choice. It would allow you to take advantage of most of the provided functionality, such as NSDocumentController, undo support, window management, etc. You will have to override some methods, such as loading and saving. It might be difficult to get the "Open Recent" menu to work correctly for these documents (maybe use a custom URL scheme?). The disadvantages of using NSDocument are... none that I can think of. You would have to write everything from scratch, and it would be even harder to integrate them into the rest of the application.

ughoavgfhw
  • 39,734
  • 6
  • 101
  • 123
  • Many thanks - that looks like that then :) Can you elaborate on the custom URL scheme please? Are you referring to a way of uniquely identifying a database item so that the 'database item document class' will be selected when an attempt is made to open it? – trojanfoe Jan 26 '12 at 07:46
  • Exactly. You define a custom scheme and indicate that your application supports it. The URL would contain the path or URL of the database itself, and some identifier which determines which item from the database it refers to. Then you can set your document's URL using that scheme so that you can open the item directly, like from the "Open Recent" menu. – ughoavgfhw Jan 26 '12 at 17:12
  • Great - there would be no problem at all coming up with a unique *database item* identifier. Thanks again. – trojanfoe Jan 26 '12 at 18:41
1

I built my application based on NSDocument - well, actually NSPersistentDocument as it gives access to Core Data services for storing my object graph. It worked great for me and I found no disadvantages.

When you consider working with NS(Persistent)Document you will have to come up with some kind of mechanism to pass the instance of your document to the various controllers you will build to manage the views/windows and their associated data. I implemented this by creating a generic View controller class capable of holding a reference to my instance of NSPersistentDocument. All my view controllers are subclasses of this generic controller and are thus capable of easily accessing Core Data services.

My app manages 15 Core Data entities with volumes varying per entity from hundreds to hundreds of thousands instances. Not part of your original question, but you might want to consider using Core Data for object persistence. I found it to be real time saver while building my app (having worked before with PHP, Java and various DB layers which generally do not contribute much towards productivity).

Roger
  • 4,737
  • 4
  • 43
  • 68
  • Many thanks - Core Data is not an option I'm afraid - the code to read/write databases (and their items) has already been implemented in a C++ static library and I will need to use that. – trojanfoe Jan 26 '12 at 07:48