Re: Undo in conjunction with core data
Re: Undo in conjunction with core data
- Subject: Re: Undo in conjunction with core data
- From: Kenneth Baxter <email@hidden>
- Date: Sat, 22 Jan 2011 08:13:37 +0000 (GMT)
Thanks for the follow up Dave. Regarding the predicate, I understood that the fetch was entity based rather than object based, so thought that if parent != self, I would get the children of other parents too. Anyway, I can check that pretty easily.
No, I'm not directly updating a view. What happens is that the nodes are in a tree formation with connections between them, and when I add a new one, there is a layout system that gets told that there is a new node, and how big it is etc, and it moves all the other nodes and their connections around to fit the new one in, and then creates the view objects for the new node and its connection back to its parent. Quite a lot going on.
And in the deletion process, I need to send the notifications before the underlying data is removed to stop some animations and pending notifications in queues etc, and to remove some observers, so that when the nodes are deleted, there is nothing hanging around trying to access things that have disappeared. This way, the view part of the system can remove things nicely, and the layout part of the system knows that the objects have gone.
From Kyle's post, it appears that I can't get the "prior" notification from array controller observing, which is one thing I was thinking about doing.
Another thing I was thinking was about implementing the primitive set methods addChildrenObject, removeChildrenObject, addChildren, removeChildren, and calling my notifications from there, and then all the undo stuff could presumably happen automagically and the notifications would happen when I wanted them to (I'm assuming that the undo and redo mechanism would also use these methods if they are available). I'm not sure if there are any potential downsides to this, but it's another thing that I could check with relatively little work.
I think I need to have a play around with some of these ideas and see what works best for my situation, but any further suggestions based on the additional information above would be welcomed.
Thanks
Ken
On 22 Jan, 2011,at 04:52 PM, Dave Fernandes <email@hidden> wrote:
The fetch predicate would be @"parent != nil" if you want all children.
Now this is where I get a bit lost - so I presume that in my createChild method, I no longer need to post the ChildNodeAddedNotification, because I would be able to observe the change, and somehow know which object had been added?
Can you say what it is your application does when it gets these notifications? Are you just updating a view?
And for the deletion, I'm not really clear on how to get the message to all the descendants that they are going to be removed etc.
Again, what do the descendants need to do when they get this message? Why not just traverse the relationships to get each of the descendants and send it a message directly?
So I am guessing that there must be some way to be notified when an object is going to be added, so I can do the pre-processing, and when it has been added, so I can do the post-processing, and ditto for the deletion, but I really don't see how this can be possible since the changes are percolating up from the MOC to the ArrayController, and I don't see anything in the array controller that seems to support this level of functionality.
It sounds like you may be using the notifications to modify the data model. If so, there is probably a better design pattern.
Sorry for being dumb about this, but I think I must be missing the concept of what you are meaning in some fundamental way.
On 22 Jan, 2011,at 10:28 AM, Dave Fernandes <email@hidden> wrote:
One way to do this through the MVC paradigm is to bind an NSArrayController or NSTreeController to your managed object context (in Entity mode), and then have your view layer bind or use KVO with the selectedObjects or arrangedObjects attribute of the controller.
_______________________________________________
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