Re: Some MVC questions
Re: Some MVC questions
- Subject: Re: Some MVC questions
- From: Brent Gulanowski <email@hidden>
- Date: Fri, 19 Jul 2002 02:33:28 -0400
On Thursday, July 18, 2002, at 08:56 PM, Koen van der Drift wrote:
Hi,
Thanks everyone for your answers. It really helped my understand the
matter
better now. However, answers generate more questions.
I, uh, agree with Andrew that NSMutableArray is not the best choice for
a
superclass for a graph node class. Since you're making a DAG, I also
agree
that each node should have an NSMutableArray instance object to hold the
other nodes it points at.
Yes, I agree too :)
It cannot and should not be a subclass of NSMutableArray. Read
about class clusters.
Are you referring to the composite object in the class clusters docs?
Basically I think he meant it is a bad idea to subclass something which is
part of a class cluster. You may not get the behaviour you are expecting,
since you don't actually know the true nature of cluster objects. Use them
as instance members and wrap your functionality around them.
The controller class(es) ask the model to do things, like add, remove,
change and reorganize the structure of the data it contains. The
controller is the thing that is most related to the application itself.
Can the 'AppController' be used for this? This class is used in various
sample code I have seen (Apple, Hillegass, Beam).
Again, depends on the size and complexity of your application. The
AppController is the delegate designate for your NSApplication instance.
Generally, it handles the delegate methods and any actions that are coming
out of the MainMenu.nib objects if there is no-one else to handle it there
(as in the document architecture, where the window is stored elsewhere and
so the menu items can't send them actions unless you wire them up at
runtime).
So if you make a custom menu or menu items, they might talk to the
AppController. They might also talk to a separate controller object.
Designing controllers is an art, not a science.
Another example of the MVC paradigm in action is the re-organization of
the node's on the drawn representation of the graph. The model doesn't
need to know how the drawing looks, nor what the co-ordinates of the
drawn
nodes are -- leave that to the view objects.
So if I understand this correctly, one view iterates the array of nodes
and
tells each node "hey you, draw yourself". And another window might lists
the nodes in a table, and only tells the nodes "hey you, write your name"
.
What you've got in your head is the "object" way of doing things, but the
examples they always use in textbooks of objects "drawing themselves" is
not actually consistent with MVC. MVC says that the model never
communicates with the interface directly -- never talks to the user even
via the UI. The model minds its own business, kind of an idiot savant, a
la RainMan (sorry if that's non-PC). The controller layer (could be
multiple objects) manages the model -- feeds it information, asks it
questions. The model neither draws itself nor writes its name.
The controller also manages the view -- feeds it information and responds
to its noisy outbursts. If the controller asks the model its name, it says
it, and the controller then sends this information to the view, which
displays it in a pretty way.
Or, in a table, the table says "hey, user changed me, what do I do?"
Controller assesses the situation, and either accepts new data, passing it
down to model, or rejects data. (Now the table itself can reject data, but
only data which doesn't conform to a format. Formatting doesn't require
knowledge of the meaning of the data, only that it must conform to some
rules. The controller will interpret the data in light of its meaning.) If
this new data changes the model and has repurcussions, the controller will
learn this when it nexts asks the model for state info. The model doesn't
volunteer anything. This is user-initiated data-flow. User events flow
down (sometimes converted into more complex requests) and new results (in
the form of copies of model data) flow up.
As for controllers and how to organize them, usually you ask yourself what
your various little bunches of data sets are, and make a controller for
each. The controller retains the root object in whatever object graph
represents its particular data set. One of these is probably the real
model, while other data is to model application behaviour. Some
controllers are only around to connect the view to other controllers, esp.
in multi-document applications.
This was a very long-winded reply; I hope it was useful.
Brent
--
Inkubator: creating free, open source Mac games.
http://inkubator.idevgames.com - homepage
http://www.sourceforge.net/project/inkubator - project page
http://64.246.17.165/forum/forumdisplay.php?s=&forumid=17 - discussion
forums
_______________________________________________
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.