Re: Some MVC questions
Re: Some MVC questions
- Subject: Re: Some MVC questions
- From: Brent Gulanowski <email@hidden>
- Date: Thu, 18 Jul 2002 17:52:41 -0400
On Thursday, July 18, 2002, at 03:32 PM, Koen van der Drift wrote:
Hi,
I have some questions regarding the implementaion of the mvc paradigm in
my app. My app displays a datamodel (a directed acyclic graph, to be more
precisely) in a window. The user can edit the graph by dragging nodes
from a palette (in a separate window) to the main window, or by selecting
the nodes and delete them, or move them around.
So, this is what I have in mind:
Model: the graph itself - probably a subclass of NSMutableArray, and each
node is a subclass of NSObject.
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. On to your real question:
In simplest terms,
A model is the data and methods that act directly on that data,
irrespective of where that model is used or how it is viewed.
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.
The view does two things:
1) accepts, filters (enforces range limits and the like), and passes on
input from the user, blissfully unaware of how it will be used.
2) accepts interface state update directives from the controller. Eg: user
has zoomed into your image as far as is allowed, so inactivate the zoom-in
button, and eg: here's something new to draw, draw it.
Apparently your application is small enough that you rolled the controller
tasks into the view objects. This isn't necessarily bad, but it means that
your view objects aren't reusable any more. If you want to be strict with
the pattern, take out decisions where the view is acting on itself in a
way that is particular to your application.
View: MyGraphView, a subclass of NSView. This forwards received drags and
mouseclicks to the graph. And it draws the graph (actually it tells the
graph to draw itself in the view)
The mouse events should be filtered for essential data and then forwarded
on to the controller. You might even forward the events on without
changing them at all, but some pre-processing might be sensible.
Likewise, the view should tell your controller that it is time to draw,
and the controller can decide for itself whether to tell the model to draw
itself. In addition, you might consider that the model should not know
anything about the view, such as how to draw in it, but instead the
controller might wire the model up to a set of objects which draw a
representation of the parts of the model. This way, you could have the
user draw the graph in different colours, with different shapes, etc. as
outlines or boxes or whatever, and the model would never need know. In
fact, you could wire the model up to a text interface or a 3D interface,
and likewise it would neither know or care. That is MVC.
Controller: ??? - now I am stuck. What should this class take care of? Is
it an intermediate between the view and the graph, eg when an object is
added or moved?
Controller *interprets* the user's interface gestures (mouse and keyboard
actions) and converts them into commands to the model to change itself,
and it reciprocally sends update messages to the view objects to reflect
the state of the model.
And how does the palette fit into the MVC scheme?
The palette is part of the View. It doesn't know anything about the model,
or how the model is used, it only has little pictures on it that have
some kind of indentifiers: the picture is recognized by the user, but the
tag (or similar) is what is sent to the controller. The drawing view knows
nothing of the meaning of the picture or the tag, only that it has to send
a tag when the picture is dragged onto it.
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. If the user moves them
without changing their connections, the graph hasn't changed, so the model
shouldn't be changed either.
The view is a representation: one of many. Keep that in mind, and you will
find the distinctions easy to remember.
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.