Re: Core Data design question: receiving KVO notifications of partially mutated objects
Re: Core Data design question: receiving KVO notifications of partially mutated objects
- Subject: Re: Core Data design question: receiving KVO notifications of partially mutated objects
- From: "Sean McBride" <email@hidden>
- Date: Mon, 2 Nov 2009 18:11:07 -0500
- Organization: Rogue Research Inc.
Graham,
Thanks for the detailed reply!
>I'd say you're going down the wrong path there.
Agreed, hence my post. :)
>Set each property individually. Yes, it will trigger a notification
>for each one - doesn't or shouldn't matter, and unless you can show it
>causes a performance problem, shouldn't be a cause for worry on that
>score. It won't cause multiple redrawing, because even if each one
>posted a -setNeedsDisplayInRect:, the actual drawing will not get
>processed until the next update cycle and invalidating the same area
>three times still only results in one redraw, by which time all the
>properties will be set. Drawing performance is not an issue here
>(unless you are bypassing the update mechanism and forcing the drawing
>on a notification, but that's a different wrong, so you're not doing
>that, are you?).
My 'Rectangle' object with colour, width, and height attributes was an
example of course. I should probably have clarified that or just not
have used drawing as an example. You are right about the whole redraw
mechanism of course, and my drawing is in fact fine, and I'm not doing
anything mischievous there.
>The question of whether the separate notifications lead to an invalid
>intermediate state is a more reasonable problem to consider, but it
>normally shouldn't matter either. Normally KVO will be used to update
>your UI and/or maintain undo. You mention Core Data so that will
>handle undo for you but even if you were doing that yourself it
>shouldn't matter. Undo will record each property change and group
>them, so you end up with one undo that undoes all three property
>changes. Any UI that represents each property will also update all at
>once (or appear to) because the drawing update cycle won't actually
>show changes until the update runs and flushes the changes to the
>backing store.
In general, I've found things do indeed work that way, and they work well.
>As a general rule you can and should treat each property in isolation.
>Even if some command sets several at once, you should find that it all
>works correctly unless you've gone out of your way to depend on some
>property state always being paired with some other property state, in
>which case you should probably make that state pair a separate
>property. I think as a general rule the approach you're proposing is
>unnecessary and untidy.
I'm starting to think perhaps the root of my problem is that I am using
KVO in my controller layer to do things that should be done in my model layer.
Sometimes the creation of one ManagedObject, say type 'Foo', requires that:
- several other ManagedObjects be created and related.
- several existing ManagedObjects be found and related.
Where is the right place to do such a thing? Currently, I often do it
by KVO observing, in my NSDocument, the creation of new Foos. When I
detect new ones, I'll perform some fetches, create new objects, relate
them appropriately, etc.
(In the past, I tried doing such things inside Foo's awakeFromInsert but
I discovered that performing a fetch from that function leads to various
problems.)
Thanks,
--
____________________________________________________________
Sean McBride, B. Eng email@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
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