Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MVC and Cocoa text system

On Tuesday, July 30, 2002, at 07:56 PM, Eric wrote:

The recent thread on MVC class design got me thinking about MVC separation
in my own app. I have a menu item action connected to the First Responder in
MainMenu.nib. The action method programmatically changes the contents of an
NSTextView.

Currently, I have the action method implemented in an NSTextView subclass. I
subclassed NSTextView for another reason altogether, but I figured since I
already have a subclass, I might as well implement the action method in it.

After reading Apple's documentation on application architecture, which
states that logic specific to an application should be implemented in
controller objects, I'm thinking that the action method should be
implemented in the text view's window controller instead.

What are the advantages and disadvantages of each approach? Implementing the
action method in the NSTextView subclass seems more direct to me, in the
sense that it is the object whose contents need to be changed, so it should
respond to the menu action, rather than waiting for it to travel up the
responder chain to the window controller.

As a side question, should I not be making changes to the text view at the
NSTextView level at all since it is a view object? I.e. Should I subclass
NSTextStorage, NSTextView's model class, and make the changes there?

There is no single definitive answer to questions of this sort; every case is different. Generally speaking, it is perfectly reasonable to place action methods on a view, especially if they are tightly associated with that view, and independent of other application state. For example, NSTextView has an underline: action method, which adds an underline attribute to the current selection. If for some reason you needed an action that would underline the first character of every selected word, it would be quite natural to create an underlineFirstCharactersOfWords: action method in a category on NSTextView (or a subclass if you already have one).

On the other hand, an action that depends heavily on state elsewhere in the application, or otherwise highly specific to this application, might be better placed on a controller. For example, if you had an action method that appended your application's log file to a text view, you might want to create an appendLogFile: action on one of your controller objects.

In general I recommend that those who are customizing the text system consider first notification, then delegation, then categories, then subclassing of text system objects. The reason for this is that subclassing kit objects is the most powerful and general of these mechanisms, hence also the most dangerous; it should be reserved for cases where it is truly needed. It also seems to be the mechanism many developers think of first, so as an antidote to this I recommend considering all of the others before it. Of course, subclassing is still necessary and appropriate in many cases.

In answer to your side question, it is perfectly appropriate for an NSTextView to make changes to its underlying NSTextStorage; text view methods do that all the time. You would subclass NSTextView, for example, to change the way that your view interacts with the user; you would subclass NSTextStorage, for example, to change the way in which text is stored or some behavior of its storage. If you have some complex modification to the text, that might be called from multiple places, it might be reasonable to add a method in a category on NSTextStorage to perform those changes, and have an action method in your view or controller then call that method on the text storage.

Douglas Davidson
_______________________________________________
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.
References: 
 >MVC and Cocoa text system (From: Eric <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.