Re: NSDocument-based architecture suiting my NSBundle-based documents case?
Re: NSDocument-based architecture suiting my NSBundle-based documents case?
- Subject: Re: NSDocument-based architecture suiting my NSBundle-based documents case?
- From: Mike Ferris <email@hidden>
- Date: Mon, 18 Apr 2005 07:50:54 -0700
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?
In your application delegate implement -applicationShouldOpenUntitledFile: and return NO.
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: ?
In app delegate implement -applicationDidFinishLaunching: and run your open panel there. Maybe by calling [[NSDocumentController sharedDocumentController] openDocument:nil]... But you may also want to ask first whether the user wants to create a new document and open an existing one.
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.
In untitled documents Save always acts like Save As... If you do 1 & 2 you will not have untitled documents. Presumably when you create new documents you will ask the user for a save location first... Do this by catching the -newDocument: action in your app delegate and running a save panel, then you can call NSDocumentController's -openUntitledDocumentOfType:display: to make a new doc and use -setFilename: to give it the name the user chose from the save panel.
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?
This would be a bit weird... Xcode has a multi-level document scheme (projects and files within the project) but the disk forms of these two things are distinct even though they're logically a containment. You should think hard about how much sense it makes for the user to be saving pieces of what is a single document to them.
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?
You only implement one pair of these. If you're saving folder-based documents, then the "dataRepresentation" methods are not appropriate. You should either do the file-wrapper based ones if NSFileWrapper is a good solution for representing your bundles, or the file-based ones if you just want to be given a path and have the rest be up to you.
These pairs of methods cascade in order of less to more work: dataRepresentation, fileWrapperRepresentation, file. The NSDocument stuff will call the rightmost pair (in the order I just gave) that you implement.
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.)
Is the audio file part of your bundled document? Or is it just referenced? Does it have separate UI?
If it is part of your bundle, then it should all be one type. Otherwise it should be two. If you have two types in your Info.plist then the document system will figure out (based on file extension or type) which NSDocument subclass to create for a given file. Then, your NSDocument subclasses can make finer distinctions if necessary (say .mp3 vs. .aiff vs. .wav for audio files).
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.
It will ultimately cause whatever pair of methods you implemented above in #5 to be called. The idea here would be relevant for you if audio files are to be part of your bundle, or if the only reason you open audio files is to make an annotation document and there's not really any separate UI for the audio file. What it suggests is that you can make a document so that if it loads a file (a raw audio file, for example), that after reading the file and creating a new annotation document backed by that file, you could rename and retype the document to be an annotation bundle.
More concretely. Let's say you allow the user to load ~/Documents/MySong.mp3 and you want that action to basically create a new annotation document for it. In an override of readFromURL:ofType: and readFromFile:ofType: you would first call super. this would eventually cause your -loadFileWrapperRepresentation:ofType: to be called to load the file... you would create an empty annotation document backed by the sound file. Then, back in the readFrom... you would call [self setFilename:@"~/Documents/MySong.annotationBundle"] and [self setFileType:@"MyAnnotationBundleDocumentType"]. Now, the first time the user saves, it will be to a new file wrapper next to the original sound file.
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?
NSWindowController controls one window and a window is controlled by one NSWindowController.
You might want to look at MOKit's MOViewController for a solution that allows you to have different controllers for different bits of a single window (different tabs of a tab view, different splits of a split view or whatever.) http://mokit.sourceforge.net
Mike Ferris
_______________________________________________
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