Re: Some MVC questions
Re: Some MVC questions
- Subject: Re: Some MVC questions
- From: Brent Gulanowski <email@hidden>
- Date: Fri, 19 Jul 2002 01:31:22 -0400
On Thursday, July 18, 2002, at 08:22 PM, Cameron Hayne wrote:
On Thursday, July 18, 2002, at 05:52 pm, Brent Gulanowski wrote:
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.
But what about saving the state of a view (so it comes up the same way
next time)? Usually it is the model which gets saved to a file. How would
you handle this? I'm thinking you would have a separate 'v-model' which
would store things like node coordinates. Then the view would query the
controller for both the node-model data and the v-model data. And this
would seem to indicate the need for some sort of node-identifier to tie
together the two models. Of course it woudl be much simpler programming
to just have the coordinates stored as part of the node!
Yes, I agree; certainly these things are open to interpretation, and no
pure pattern is always useful, I'd wager (just like any other discipline).
But what's interesting is that the controller is in charge of how the data
gets put onto disk, so it could always do the display model as a parallel
set of data. For best portability of the model, you'd want to assess
whether the display data was essential or secondary. For an app like
Illustrator, it's the same thing, because the presentation is everything.
For an abstract graph which might have multiple modes of representation,
its less clear, especially if your drawing system is OS-dependent (unlike
say, OpenGL). But chances are you would just store the display information
in a format which was generic, and then adapt that when displaying it in a
particular way. So you'd save the size and co-ordinates, and then pass
those to the view objects which end up drawing the nodes (and edges) on
screen.
It's very analogous to storing text vs. storing a Word document. There's a
whole heap of layout (I almost said "rendering") instructions included,
and while they aren't as essential as the text itself, they are valuable
and must be preserved. In the file, its just data. When the file is loaded,
that data gets wrapped into objects. Are those model, view, or controller
objects? Maybe MVC is too simplistic in this situation. If they are
retained by the model, I guess they're model objects, even if the view
might be able to copy them and use them as is. See, that's an important
distinction. If the view uses the data whole, it should still copy it, and
never modify it.
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.