Re: General MVC and ownership question
Re: General MVC and ownership question
- Subject: Re: General MVC and ownership question
- From: Graham <email@hidden>
- Date: Wed, 5 Mar 2008 09:59:37 +1100
Thanks for picking up the ball on this one Jens, much appreciated.
I had more or less come to the same conclusion about having one
controller per view, with the data model owning the controllers.
My actual situation is that the "data model" is in reality a vector
drawing stack with layers, objects, groups of objects, etc. laid out
on a "canvas". The "canvas" is a self-contained container object that
could be owned by a document but is not in itself a document, though
typically there might be a 1:1 correspondence in a typical app.
The view is there to render the contents of this drawing. There can
be more than one view, either in different windows or in the same
window (split view). So the "data model" includes methods to render
itself into a nominated view on demand. Similarly, when something
changes state in the drawing, the relevant areas of the views are
flagged for update - this is why currently the data model keeps track
of its views.
So if a controller is placed between the data model and the views,
for this case it's not going to be doing much - just passing on the
drawing (and user event) requests one way and the update requests the
other. It seems to me it would be very complicated for the controller
to handle the drawing task in the sense of asking the data model for
its objects and then working out how to render them in the view. The
organisation of the data model already makes this task much easier
since the natural order that things get done provide the back-to-
front ordering of layers, objects and so on, and the objects
themselves know how to render themselves in a variety of ways. Does
this make any difference to the answer? I can imagine a different
sort of view controller existing for some unusual case such as
showing a list of objects rather than drawing them, which the current
approach supports but in a less generic way.
The question about ownership is because the system can be built in
two ways - either assembled by the programmer, or automatically. In
the automatic case, simply placing the right sort of view in a nib
creates a complete default "back end" for you - in this respect it's
very much analogous to NSTextView that builds the editing back end to
support the view you add to the nib. So in this latter case where the
view builds the back end I'm keen to avoid a retain cycle since the
normal ownership situation is partly reversed, in that there's not a
one-way "flow" of ownership from document to data model to controller
to view - the view has to create the data model and hence retain it.
I do need to support 10.4, so I'm not using G/C. However I'm
comfortable with the retain/release mechanism in general.
--------
S.O.S.
On 05/03/2008, at 4:05 AM, Jens Alfke wrote:
On 3 Mar '08, at 6:16 PM, Graham wrote:
The question is: would the better design be one-controller-per-
view, or a single controller supporting multiple views? In other
words should the controller typically associate with a single view
or the data model?
Generally there should be a controller per view. This is because
the controller directly operates on the objects in the view (it has
IBOutlets, in Cocoa terms), and because you might have different
kinds of views (like list vs. icon) that require entirely different
controller implementations.
The follow-on question would then be: what would be considered the
optimal "ownership" relationships between the various objects in
the system? Do data models typically own their controllers, or
should the controller(s) own the data model?
There's usually a central "document" object that owns the
controllers, which in turn own the views. You can think of the
document as an über-controller.
Cocoa supports this model via the NSDocument and NSWindowController
(and now NSViewController) classes.
Have you considered using GC? I'd recommend it, if your app doesn't
have to support 10.4, and if it doesn't depend on 3rd party Cocoa
libraries that aren't GC-ready. It makes this stuff so much easier.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden