Re: protocol vs. subclassing NSView
Re: protocol vs. subclassing NSView
- Subject: Re: protocol vs. subclassing NSView
- From: Michael Ash <email@hidden>
- Date: Sun, 22 Feb 2009 08:20:53 -0500
On Sat, Feb 21, 2009 at 8:48 PM, Development Staff
<email@hidden> wrote:
> So I've got this app that uses various NSView subclasses (NSTextView,
> NSImageView, QTMovieView, etc.) to display different kinds of data in a
> window. The problem is that, when I need to select which kind of view to use
> for the current data, I have very different code for each kind of view
> (detecting what view handles the current data and initializing the view),
> and it currently makes for a messy bit of code.
>
> What I'd like to do is have an array of candidate views and a consistent way
> to test against the current data and initialize the view once I have
> selected a candidate. I'm trying to decide between a formal protocol with
> -(BOOL)canDisplayData:(id)data and -(int)setupDisplayInFrame:(NSRect)rect
> withData:(id)data methods, or a sub-class of NSView from which all candidate
> view classes must descend.
>
> I'm currently coding against the protocol, but reading the Cocoa Views Guide
> to see what kind of work I'll need to put in to correctly wrap the actual
> candidate views. If all I really need to do is pass on calls to -drawRect
> calls to the actual view, then I feel comfortable going with the protocol.
> If there is a lot more to it, then putting all that work in a separate base
> class seems like the right thing to do.
Passing on calls to -drawRect: will not work. For example, a view may
invalidate itself when it changes. It's going to invalidate *itself*,
not your proxy view, and so the whole thing will fall apart.
You could have your custom view and then add the "real" view as a
*subview* rather than trying to proxy drawing across. The end result
will look the same.
Better yet, since your custom view doesn't actually do any drawing, it
should really be a custom controller. Instead of trying to move your
code into a view, just move it into a separate controller, in
different classes which descend from a common subclass. Then your
generic controller can instantiate and talk to your specific
controllers and all is handled.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden