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]

Reply via email to