NSDocument-based architecture suiting my NSBundle-based documents case?
NSDocument-based architecture suiting my NSBundle-based documents case?
- Subject: NSDocument-based architecture suiting my NSBundle-based documents case?
- From: Dirk van Oosterbosch <email@hidden>
- Date: Sun, 17 Apr 2005 01:36:52 +0200
Hi All,
I think I have a special case (don't we all? ;-)) of a "document"-based application and I am wondering how the NSDocument-based architecture can fit my needs. Let me first explain my case. Then I'll list my questions I have with NSDocument and his companions.
I am building an application for the annotation of audio. i.e. there are (heavy) audio files, which my app cannot edit but can play. And there are annotation files which the user can edit.
There are multiple annotation files per audio file (context-annotation, keyword-annotation, link-annotation, ...). And all these files (1 audio + n annotation) are wrapped in a NSBundle. So I have a directory which looks as a file to the user, with has a /Contents/ directory inside, which has inside a pkgInfo file, a Info.plist, the audio file and these annotation files. I am using the information property list (Info.plist) to store the details of that wrapper (bundle, whatever): the location of the audio file and which annotations it has, and the paths to these annotation files.
(I hope I am not boring you with this, I just want to be clear about the specifics of my model.)
Now my questions about the NSDocument-based architecture:
1. The NSDocumentController should NOT create new empty files in my case. (There is nothing to annotate when there is no audio.) How can I disable the newDocument: behavior?
2. The NSDocumentController (or the one in control) should first be displaying a modal window when the user opens an audio file. From where / when can I call this modal and should I then have the modal call the NSDocumentController openDocument: ?
3. The "save as" behavior should also be disabled or first present the user with a sheet. But probably when I found the answers on 1. & 2. the answer on this one is there as well.
4. I didn't make my mind up completely about saving, but I was thinking it would be rather nice if the user could save individual annotations. However, I fear that this is really breaking the NSDocument architecture. (I would be a bit like in Xcode where you open a project and then save the individual .h & .m files. But then again my app shouldn't allow users to *open* individual annotation files, since it doesn't make sense to edit an annotation without a audio file.) But if I did want to do that I would need a "Save" (single annotation), "Save all" (all annotations of one bundle, comparable with the saveDocument:) and a "Save all wrappers" (comparable with "saveAllDocuments:). How could I do that? And how would you guys advice me on this?
5. I reckon I should override -readFromFile:ofType (& -readFromURL:ofType) and -writeToFile:ofType (& -writeToURL:ofType) for my composite file format, but should I also override -dataRepresentationOfType and -loadDataRepresentationOfType? And what about -fileWrapperRepresentationOfType and -loadFileWrapperRepresentationOfType? Should I also override these? And what should I be putting in their implementation?
6. From the documentation I read that NSDocumentController differentiates between different files to be handled by different NSDocument subclasses. I have different file types that can be opened: audio files and my own annotated-audio-file-wrappers. But does this apply to me? Or can I also just check for the file type in -readFromFile? (which looks like getting heavier and heavier.) Moreover it seems that -readFromFile is a little late to check for the type and decide what to do. Can I check for that filetype earlier? (sorry to repeat parts of question 2. here.)
7. In the NSDocument FAQ ( http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Tasks/FAQ.html ) it says "
If you want to automatically convert them to be saved as your new type, you can override the readFrom... methods in your NSDocument subclass to call super and then reset the filename and type afterwards." What exactly does the abstract implementation of NSDocument do when I call [super readFrom ...]? How can I tell it to deal with my wrapper format, or how why should I call super? I am confused.
Finally.
I should probably start a new thread from this question, since I seems not be strictly dealing with NSDocument or NSDocumentController, but nevertheless:
8. I want to use several different nib files for the different annotations edit interfaces, but I want to put them all in one window. (as subview of a tabView or splitView). Should I subclass NSWindowControllers for them? I am not creating windows, just views. And where should I put the other "annotation"-logic? Or use separate controller classes (NSObject decendants) maintained by myDocument class?
Sorry, if I am spilling too much questions in this long mail ... (and I haven't even started about maintaining all my "documents" in a playlist file, which then becomes the head document...)
Any help is welcome.
Much obliged,
Dirk van Oosterbosch
-----------------------------
Dirk van Oosterbosch
de Wittenstraat 225
1052 AT Amsterdam
the Netherlands
T ++ 31 20 7765565
M ++ 31 6 48401910
W http://labs.ixopusada.com/
-----------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden