Question

I am about 90% sure my program would benefit from using the document framework in Cocoa but there is one thing that I am unsure of.

In all the examples I have seen, The NSDocument subclass always represents the file being saved which isn’t entirely appropriate for my application.

The file that will be saved to disk in my application will be a collection of the entities that will be edited within the program. When a new file is created the user will be able to edit the individual entities contained within that collection which will require state and change tracking (Save, undo etc).

Will a document based application work this way or will I be constantly fighting the framework?

Updated to make my question clearer:

I was planning on saving the file as a bundle as it will certainly make it easier to manage the separate entities contained within the file but doesn’t really address my question.

Think of a program like Microsoft Access; The file is the database but the documents are things like forms, reports, queries and macro’s. Each item is edited in a separate document window and changes can either be saved or undone to the individual documents but it is the whole database (including all the forms, reports and queries) that is saved.

Answer 1

I am not sure wether this apply to your application, but you could associate your NSDocument with a package, so that your document would be not just a file, but exactly the collection of files you require to work on.

When I worked on this a few years back, it was not so trivial to get this working, but in the end it could be done. I hope that things have got easier by now, but anyway, if it is suitable for your requirements, I would give it a try.

This S.O. topic will give you a hint at what must be changed in the default NSDocument.