I haven't delved into the Buck Book yet, but I thought I would offer my take on the use of Views. IMHO, Cocoa and its sample code, like MacApp, makes far too much use of subclassing views for encapsulating complex functionality, e.g., NSTextView, in violation of MCV. In MacApp, I made copious use of Behaviors to rectify this and even wrote several articles in MacAppDigest on this subject. In Cocoa, it could (IMHO, should) be done with controllers.
One approach I have made to solve part of the problem for my own views is to use a generic view (RTPDisplayView) in which I add two delegates, i.e., (id)displayDelegate and (id)editDelegate. The former serves solely to forward the view's drawRect to a displayController. The second serves solely to forward drag/drop commands to an editController. The displayController is an NSObject. The editController is a NSResponder which in "awakeFromNib inserts itself into the responder chain following the view. Of course, there is an IBOutlet back to the view when needed -- mainly for invalidations, drag/drop registration, etc. I do occasionally use other controllers to handle view-related functions, such as resizing, scaling, etc. In the case of shape editing, the editController has grown to substantial proportions. Still, I believe it is better in the controller than in a subview. I have given thought to sub-partitioning the editController and chaining the resulting controllers into the Responder chain similar to what I did with behaviors in MacApp. Maybe later. Another advantage is that the same view can be used for handling many types of situations by swapping out the display/edit delegates instead of removing/adding views. This generic view has served me well. It has allowed me to do just about anything I want in the controllers without subclassing the view. Also, the partition of functionality between display/edit controllers has been useful because some cases only do display and no editing, e.g., preview/look-ahead windows. I offer this because I believe it is a useful design pattern when dealing with views. I hope the concept proves useful to others. _______________________________________________ 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 [EMAIL PROTECTED]