Thanks to all for the answers. Since I wasn't planning on a tree type view, I
missed the inherent tree nature of the model. So having a mediating layer of
objects (Nodes) seems to be the way to go.
Martin
On 12, Jun, 2011, at 10:08 PM, Quincey Morris wrote:
> On Jun 12, 2011, at 12:12, Martin Hewitson wrote:
>
>> Suppose I have a model object Parent which contains an array of Child
>> objects.
>>
>> Then I have a ParentView object and a corresponding ParentViewController.
>> The controller has a reference to the Parent and to the ParentView and so
>> can act as a data source for the view. So far, so good.
>>
>> What I'm unsure about is, how to deal with the children objects. I will, in
>> principle, have a ChildView. This raises some questions:
>>
>> 1) Should I have a ChildViewController class?
>> 2) Where do I keep the array of ChildView classes? In the ParentView? And
>> how do I ensure that each ChildView is associated with the appropriate Child
>> object?
>> 3) If I do have a ChildViewController class, where should I keep the array
>> of these? In the ParentViewController?
>
> Here's how I've done this:
>
> -- You need a class to represent your data model objects in the user
> interface. In the past I've rolled my own, but now I would suggest starting
> with NSTreeNode and subclassing it.
>
> -- In your NSTreeNode subclass, add a "representation" property of type 'id'
> to go along with the "representedObject" property it already has. Note that
> you only need one NSTreeNode subclass, since you find out what an instance is
> used for by looking at the class of the instance's "representedObject" and/or
> "representation" objects. (In particularly complex designs it might be
> worthwhile having multiple subclasses, but I wouldn't do that unless it
> proved necessary.)
>
> -- The tree node's "representedObject" is set, of course, to a Parent or
> Child or other object in your data model.
>
> -- The tree node's "representation" is set to a NSViewController (possibly a
> subclass if you need it) that represents the ParentView or ChildView.
>
> -- By setting the tree node's "parent" and "children" relationships, you
> construct a hierarchy of tree nodes that encapsulate both the data model (via
> "representedObject") and the views (via "representation"). The hierarchy
> often matches the hierarchy in the data model, but it doesn't have to.
>
> -- It's often convenient to have some tree nodes (e.g. a root node) that
> don't correspond to a data model object, and you can set the
> "representedObject" to nil or something else. Similarly, it's often
> convenient to have some that don't correspond to a view. In that case, I
> typically set the representation to a string. Sometimes the string *is* the
> representation of the object that you want to draw somewhere in the UI (e.g.
> in an outline view); sometimes you can use it just as a way of recognizing
> the node.
>
> In your controller, you work with the tree nodes primarily, because you can
> get from them to the data model and the views.
>
> If you need a ParentViewController and/or a ChildViewController that's a
> subclass of NSViewController -- and you probably will -- then by all means
> use them. They're mediating controllers, though.
>
> For your coordinating controller, you almost always should use a window
> controller subclass, and *not* (for example) the ParentViewController. The
> window controller is responsible for building and maintaining the tree nodes,
> and for arranging for the correct set of parent and child views to be visible
> at any given time. Almost all of such behavior needs to consider the window
> context as a whole, so it tends to confuse matters to tie the behavior to a
> specific view.
>
> I believe that the above arrangement makes use of the current "best
> practices" for window controllers, view controllers and views, and I've found
> the design pattern very easy to work with.
>
> HTH
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer
Gravitationsphysik und Universitaet Hannover
Callinstr. 38, 30167 Hannover, Germany
Tel: +49-511-762-17121, Fax: +49-511-762-5861
E-Mail: [email protected]
WWW: http://www.aei.mpg.de/~hewitson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
