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 15:02:11 -0400
On Friday, June 13, 2003, at 12:57 PM, Scott Andrew wrote:
My take is my model will be responsible for reading the data and
creating my media objects in the order they are layered (background
image, background movie, dropzone, buttons, etc). Also will handle
asking each item to write them selves to the file properly. Model
would also have things like dimensions, theme name, basic overall
information. My view would get a mouse click tell the controller
where the controller tells the model something was clicked and then
model finds the object and tells that item it has been clicked. Which
then changes the focus object and that can send a notification to
update the view and update the properties window.
I think that when the model involves graphical data or other data that
is almost ready-to-render, it is more of a challenge to identify where
the model stops and the view begins -- let alone where to put
controller code. You're in totally WYSIWYG mode, since you are writing
an application to make data for display, and it should look basically
identical. The difference would be that your view will probably have
lots of extra information, like sizes and locations and angles and
guides and layer markers and all that sort of stuff, which is going to
be different in the model than in the view, and won't make it into the
exported file, either. So my advice is to concentrate on the workflow
that you are creating, because the model is behaviour as well as data
-- behaviour like reading user requests to move things around. So
basically in the view every bit of data is transitory. It should have
no "memory" if you can help it.
Remember, views get "clicked", while objects in the model get changed
and/or selected (focussed). Subtle but important difference. So the
controller does not actually tell an object "you have been clicked"
unless that affects the object's state. for a get info (properties)
display, usually the controller would get the click and convert it into
a selection, request the view to identify that selection (highlight or
whatever). The controller would then request the properties data from
the object, possibly change its format to be more suitable for display.
Depending on the design, it might then directly tell a view that it had
new data, or change the data source and tell the view that it was time
to update itself. The messages go 'round and 'round. But if you have
multiple views to update, this works really well.
--
Brent Gulanowski email@hidden
http://inkubator.idevgames.com/
Working together to make great software.
_______________________________________________
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.