Re: [UNSOLVED] How to observe every child entity
Re: [UNSOLVED] How to observe every child entity
- Subject: Re: [UNSOLVED] How to observe every child entity
- From: Jerry Krinock <email@hidden>
- Date: Wed, 16 Sep 2009 19:44:44 -0700
On 2009 Sep 16, at 18:25, Matthew Lindfield Seager wrote:
Someone kindly warned me off-list about taking care when an item is
deleted and then re-added by an Undo ... When a user undoes a
deletion it calls the primitive accessor which does not emit KVC/KVO
notifications.
How about if you calculate the calculatedBalance in a custom setter
whenever a user updates/adds/deletes a transaction, and store its
value as a regular property instead of a derived property. This way,
everything is "in the model". Both the transaction change and the
calculatedBalance change will be stored in the undo group, so that
when Undo happens, everything gets changed back to original values.
I also get the feeling that this issue is similar to other people's
previously discussed issues and that I'm going to need to take over
the undo/redo responsibilities from the NSArrayController (as
mentioned in this post...
Well, the Wil Shipley School of Undoing Core Data Doodoo teaches a
good lesson if your app is like Delicious Library in the sense that
you count the number of changes that a user might make on one hand,
and therefore write the requisite undo code in a few hours. But the
Core Data <-> Undo Manager interaction is, I'd say, another issue.
1) Is my gut feeling about not using primitive accessors to manage
observers correct?
Ah, I should have read your code more carefully. Indeed, the part
where you invoke will/didSetValueForKey...
NSLog(@"pretending to change calcBalance so observers will know to
get it again");
is particularly nasty and always an indication that it's "time to step
back".
2) Is there a simple way to override that small aspect of the undo/
redo system (as I'm lazy and everything else is working well) or do
I need to implement undo/redo myself?
I don't think you want to do that. When I had similar issues a few
months ago [1] I decided that the solution was Custom Setters. My
code is full of custom setters. They're brute force and ugly, but
they work because they get all the data into the model, where Core
Data can get to it and do what Core Data is good at.
I filed a bug on the difficulty of handling derived properties with
Core Data and posted its text. You might want to read this [2].
1. http://www.cocoabuilder.com/archive/message/cocoa/2009/2/26/231055
2. http://www.cocoabuilder.com/archive/message/cocoa/2009/2/26/231066
_______________________________________________
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