Re: The more I read about MVC, the more confused I get...
Re: The more I read about MVC, the more confused I get...
- Subject: Re: The more I read about MVC, the more confused I get...
- From: Brent Gulanowski <email@hidden>
- Date: Fri, 13 Jun 2003 11:42:13 -0400
On Thursday, June 12, 2003, at 10:53 PM, Scott Andrew wrote:
On Thursday, June 12, 2003, at 07:01 PM, Brent Gulanowski wrote:
Hrm, not sure I understand this one clearly. Unless you are filling
the pop-ups programmatically and dynamically, wouldn't it be better
to just set them up in IB? Otherwise, if the dictionaries aren't part
of the model, then a view controller should own them, I believe. The
rest would be standard target-action stuff. The view should be very
stupid about anything but itself. It is there to present controls,
but it doesn't know what those controls mean, only how to report that
the user has interacted with them, and what state they are in. The
view controller retrieves that state information, and passes it onto
the document in a format more suitable to the model. Then the
document updates the model, because it knows the details of the
model's interface.
For single-window apps, this division of the controller into two
layers can be considered optional. Even if you don't make custom
window controllers, the document controller will, but you don't have
to know they are there. Your controls and views can talk directly to
the document. Because controllers are mostly just collections of
methods, with little or no state, the locations of those methods is
partly a matter of being organized, although changes to the view will
necessitate changes to the view controller, so it is good to have it
de-coupled from the document logic.
I am a newbie planning a project and have some questions along the
same lines:
Ok I have this question. I am working on a small graphics app that
takes a bunch of media displays them for the user to to layout then
spits out a package. I have my heirarchy setup so that i have a few
different media types TBMedia is the parent it just holds a path, a
rect, and some simple commands. Then children there are children of
TBMovie, TBImage, TBText. I have a TBDataModel that knows how to open
my packages and translate them to the proper classes, it is also used
to import images and create the proper object. The controller also has
the order they are layered. Also it is used to make sense of the media
heirarchy's and spit out my dictionary of media and positions. If each
of these types has a view assocaited with them, would the media types
be considered my controllers? Each media type has properties that are
associated with them that can be modified using a sheet similar to
Interface Builder.
I think the media types would properly be considered view types, but in
the case of a pre-rendered movie (and with 3D, which I have thought
about more), the lines are very blurry. Because a movie is not
interactive, it is not explicitly a model, although it could be
represented by a token in the model. The model decides when to activate
the token, and the controller reads this (perhaps through a
notification) and sends a message to the view to begin playing the
movie. As might be apparent, I find that it is much easier to think
about the view and controller after thinking about the model first, but
the application itself has to drive that. Often, the user experience is
more important and can be produced with different models. Depends on
the sanctity of the model data versus the "experience". M-V-C is about
protecting the model, first and foremost, because generally the data
and behaviour of the model are very valuable and key to the workflow of
whatever system is being modelled. You haven't addressed your model, so
I feel it is difficult to answer questions about the view and
controller layers.
My thought is a user selects the view associated with an item the
TBMedia class get's notified it has changed its state and tells the
window controller a selection has changed via a message. Also
registered with this message is the property dialog that will switch
its context. My data model is to handle things like media import and
and creation of media. The window controller tells everyone else
someone has taken selection and to do the proper thing.
What does your application actually do? I'm afraid it isn't clear. Is
it a conversion tool, or is that merely a necessary task that is part
of the larger picture?
Oh yea i am using the views to make use of the transparency.. i could
just basically draw things in the proper order in the same view as
well. My movie is painted by hand so i can layer things on top and
under it, so it requires a QuickDrawView. My other thoughts about
using views is that it would be easier to hit test, drag things
around, and manage state. But does it bog down the system if you get
too many? I am talking about 30 layers per document. So each object
gets its own view.
Does this make sense?
30 NSViews layered on one another is very much not a good idea, if
that's what you mean. This movie, is it like a .mov or .mpeg, or do you
mean a Director- or Flash-like thing, with animations and timers and
objects that the user can interact with? I'm guessing the latter, now.
That would be better if you used either Quartz drawing or QuickDraw
drawing (or even OpenGL). Within those toolkits you have to follow
their rules. Other than that, I don't know -- my graphics knowledge is
mostly 3D, what there is of it. In 3D, complicated by depth, you can
use the picking/selection system, which is part of OpenGL, not Cocoa
(or Carbon or whatever). With 2D, even in in OpenGL, you could probably
maintain a set of 2D regions and read the mouse clicks and sort them
through the regions, maybe using a tree to quickly discover which
region/object was clicked. This would be a view-managed task. When the
specifics of the user event had been determined (where and when), these
could be transferred to the object which was affected, which would then
process it some more, and pass it down to the controller layer, which
would manage the impact of the event on the model. The view only cares
about where and when, and how these affect the view's state (buttons
turning on and off), but not how it changed the model.
For example, bringing something to the foreground is a model behaviour,
so view objects should not perform them. The "I was clicked" message
will be sent to the controller, which will interpret that as a "bring
to foreground" request and submit that to the model. If the model
accepts the request (maybe the clicked thing is not allowed to go to
the front for some reason), then it will perform the request and issue
a notification (or the controller will simply re-read the affected
model object and see if it moved), and if so, the controller will then
re-arrange the view state. So, there is some redundancy, but this is
often the case when the model is media-laden. Of course, if this is
just overhead, there is no real need to subscribe to the methodology at
all. Sometimes the difference between model and view is very thin.
Sometimes the view is simply better off to have some model logic
embedded in it, especially when creating custom views specific to that
model. If they are that special, they won't be re-used, so being
modular is less important.
Brent Gulanowski email@hidden
--
keyboard not found, press F1 to continue
_______________________________________________
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.