Re: Philosophical Question
Re: Philosophical Question
- Subject: Re: Philosophical Question
- From: David Wood <email@hidden>
- Date: Sat, 4 May 2002 23:51:38 -0400
On Saturday, May 4, 2002, at 10:47 PM, email@hidden wrote:
Not knowing anything about your app, except what you write below, I
will attempt
to make some observations.
I didn't want to bore anyone with the details. The Document class keeps
track of Character-class objects and Subplot-class objects. Subplots
have roles (represented by Role-class objects) which link to the
Characters, and the Roles carry with them various benefits, notes, and
addenda (catchall class: Scriplets) that are then (theoretically)
transferred (by pointer if not ownership) to the Characters. I haven't
gotten that far with the test-app yet, actually, so it might end up
working some other way instead.
This would be development software for a very limited application, and
that's why I figured most people here would find it boring. It's been
too long since I talked to programmers in any context, though, so I
could be wrong. <:)
I think a fundamental error made when using MVC with the Document App
is assuming
that the Document is the model. It's not. The document is the
controller. It is the adaptor between the view and the model and the
interface between the model and the archived
representation of the model. Everything goes through the Document. The
reason for this
is that the document can easily keep track of changes (and thus prompt
the user to save before quitting) as well as keep the views synched
with the model.
That's what I'd observed about the Document app. I worried it did an
awful lot for a Model class -- managing its own data, maintaining its
own view, etc. In ways, it's almost its own little program.
Then a new and terrible question occurs to me: what about a program that
handles more than one kind of document? I don't see multiple Documents
going over terribly well...
BTW I always anchor my models with a root object that is not the
Document. This makes
archiving and unarchiving a snap.
How does this make archiving and unarchiving easier? Can't you
override/customize the archiving and unarchiving mechanism in the
Document class, or is there a caveat in here somewhere that I have yet
to catch onto?
Though come to think of it, the loader I need for my app will require
some serious work -- first it has to load the objects, and then it has
to restore the pointers between everything, etc. There's going to be
some funky jiggery-pokery going on behind the scenes regardless.
I don't understand what you mean about having two delegates. The
document class should mostly handle the menus. Are you unaware of how
the menu action routing occurs in Cocoa? You add actions to the
FirstResponder in the MainMenu.nib and the same actions to your
MyDocument.nib and the actions get routed through like magic.
Bah. I *meant* two Controllers. (See? See? I have only the most tenuous
grasp of the terminology!) I had the Document's window in one nib file,
and the menus in the other, and it seemed they couldn't talk unless I
did something like explicitly instantiated the Document class in the
MainMenu.nib (which now sounds like a really bad idea). I'll have to try
it that way.
--David
http://skipjack.bluecrab.org/~dwood
"Do not meddle in the affairs of wizards, for it accomplishes nothing
and annoys the pig."
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.