Re: Use of AppKit in command-line app on headless node
Re: Use of AppKit in command-line app on headless node
- Subject: Re: Use of AppKit in command-line app on headless node
- From: "Michael Ash" <email@hidden>
- Date: Tue, 12 Aug 2008 16:48:55 -0400
On Tue, Aug 12, 2008 at 1:28 PM, Rick Hoge <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden