Re: Dealing with exceptions in a drawing stack
Re: Dealing with exceptions in a drawing stack
- Subject: Re: Dealing with exceptions in a drawing stack
- From: Shawn Erickson <email@hidden>
- Date: Mon, 19 Jan 2009 10:16:24 -0800
On Mon, Jan 19, 2009 at 9:57 AM, Paul Bruneau
<email@hidden> wrote:
> On Jan 19, 2009, at 2:49 AM, Kyle Sluder wrote:
>
>> 3) You've over-architected your drawing code. Typically the fewer
>> objects that are responsible for drawing (i.e. view objects) the
>> better. Situations like the one you're describing often arise from
>> making model objects responsible for their own drawing.
>
> I was a little disappointed that Graham didn't address this point.
>
> I'm confused by it, since I have been directed in the past by people who
> know that The Cocoa Way is to have objects know how to draw themselves--via
> a category if desired.
I think the point that was trying to made is that you should do all
the heavy lifting out side of drawRect: and the only work that takes
place in drawRect: is just what needs to take place to render that
object. In other words process your data outside of drawRect:, create
what objects are needed outside of drawRect:, deal with failures
outside of drawRect:, distill what needs to be distilled outside of
drawRect: and in drawRect: just draw.
IMHO objects that can draw themselves should be NSCell sub-classes or
NSView sub-classes (possibly using some primitive drawing rendering
support from NSImage, NSString, etc.) and not some model object that
has drawing code tacked onto it. These view classes should be told or
be able to ask for the data they need to use at render time, ideally
pre-prepared / pre-fetched as makes sense.
-Shawn
_______________________________________________
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