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: Quincey Morris <email@hidden>
- Date: Mon, 19 Jan 2009 11:08:06 -0800
On Jan 19, 2009, at 10:16, Shawn Erickson wrote:
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.
I don't get this at all (not just the quoted comments, but going all
the way back to Graham's original statement).
-- If a failure in the drawing code destroys the *data model* (thereby
preventing it from being saved) then there's something terribly wrong
with the drawing code's design. (Surely, being *drawing* code it only
needs read-only access to the data model. Or, if it has drawing-
related status to update in the data model, it shouldn't be making
structural alterations to the data model whose failure could leave the
model in an un-savable state.)
In this case, the location of the drawing is irrelevant. Its design is
dangerous to the data model no matter where it's implemented.
-- If a failure in the drawing code doesn't hurt the data model, but
leads to an unending cascade of exceptions from the inconsistent
drawing state, then the problem is more about suppressing exceptions
so that the document can be saved before the application crashes.
In this case, the location of the drawing is irrelevant. The data
model is safe no matter where the drawing is implemented.
So why are we discussing whether model objects should draw themselves?
IMO, the issue is (at least initially) a matter of documentation. The
NSGraphicsContext class reference is ambiguous and incomplete -- it's
not clear whether the current context is saved *in* each state on the
state stack, or whether the state stack is *in* the current context,
or whether the state *is* the context. There's apparently a
setGraphicsState: method which *looks* like it might be what Graham
needs to set things back to a known state, but the parameter to this
method isn't documented anywhere I could find.
The header file is no help at all. The comments refer to save/restore
*context* methods (as opposed to save/restore *state* methods) which
apparently don't exist anywhere.
If the documentation was clear, I think Graham's strategy for dealing
with exceptions would also become clear.
FWIW. (Excuse the rant, please.)
_______________________________________________
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