On Tue, Aug 12, 2008 at 1:28 PM, Rick Hoge <[EMAIL PROTECTED]> wrote: > > > Thanks again for that very detailed post - I know it sounds like I'm being > lazy, but there are other parts of the app that would have to be redesigned > to allow the possibility for code use under headless conditions and it's > really important to me to know why this is necessary. What you said goes a > long way toward clarifying the underlying issues. Obviously I'm not going > to risk it now.
I'm glad you found it helpful. >>> One obvious alternative is to create a 'Data Object' class that has no >>> AppKit dependencies and stash it as an instance variable in a 'thin' >>> NSDocument subclass that just supports tasks relating to a real >>> document-based app in a window server environment. To make my app work, >>> I >>> need two layers of subclass for my documents (a general NSDocument >>> subclass >>> and several subclasses of this for specific data types) so it's a bit >>> more >>> tricky. I'd need to have a data object class hierarchy and a parallel >>> document hierarchy. >> >> If all of the smarts are in your own custom classes, why do you need a >> hierarchy of NSDocument subclasses? Have a single NSDocument subclass >> that passes all of the important methods on to your custom classes, >> and your job should be done. > > The way the app was originally designed, the top level NSDocument subclass > implements custom functionalities used by all document types. There are a > few different types of document/data that are related, but different enough > that it has worked well to use separate subclasses to implement them. For > example different nib files are loaded depending on the document type > (something that would go in the NSDocument subclass), and the data model is > different (something which would go in the data object class). Loading different nib files would be best accomplished by removing all GUI activity from your NSDocument class altogether, and having NSWindowController subclasses instead. NSDocument is built for this kind of separation of concerns (check out the -makeWindowControllers method), and in my experience it works better even for simpler scenarios. The ability of NSDocument to load and work with a nib directly is, I think, really just a shortcut for simple scenarios. As for whatever else you may have, I think the general guide is to follow MVC, and make sure you have good separation of concerns. You'll probably end up with something of a parallel hierarchy with individual window controllers that know the details of the model they're displaying, but on the other hand this is pretty standard in any circumstances. You'll end up with similar amounts of code, just split into more classes, which I generally think of as being a good thing anyway. If you separate your code cleanly into GUI and non-GUI pieces then you'll be able to run in a daemon safely and probably end up with code that's nicer to work with too. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
