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 _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
