On May 5, 2013, at 22:24 , YT <y...@redwoodcontent.com> wrote: > What I have is a view within the main window that is a Quartz 2D graphical > "thing" and I want to have a set of UI elements that a user interacts with to > change the graphical presentation. > Well the UI elements are in the Delegate and the Graphical thing is in the > view. The UI elements need to call methods in the view to change the > graphical thing.
What you've got is a MVC (model-view-contoller) pattern, which is very typical for Cocoa apps. The view is everything in the window, including the graphical thing and any controls (radio buttons, check boxes, etc) that the user interacts with to change the presentation of the graphical thing. The model is the information in the app delegate, the information that the graphical thing presents. What you need to add now is the controller. Typically, this is a NSWindowController subclass. This controller is responsible for holding references that allow the view elements to locate the model, and perhaps each other. The controller obtains a reference to the model from the app delegate, and has outlets (references) to any views it needs to access directly. The views find the controller via the nib's "File's Owner", or via outlets of their own. The model shouldn't contain any direct references to views or other objects in the nib. Note that the settings controlling the graphical presentation *could* be in the app delegate, or they *could* be in the window controller. Often, the window controller is the best place for them. (Ask yourself this question: If I was ever to allow a *second* window onto the same data, and the user was to change the UI elements controlling the presentation, what should happen? Should the presentation change in both windows, or just in the one where they were changed? If the answer is "both windows", you should keep the settings in the app delegate. If the answer is "only the window where they were changed", you should keep those settings in the window controller.) _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
