Wow, this is huge! Obviously the user doesn't expect the document to disappear and a new one open up just because they did a Save As operation, so I would have to go through every single part of the application, work out every reference to a managed object, and either throw them away or fetch new ones, and also lose the undo stack, and I'm not sure how I would keep my current selections in the array controllers and recreate all my other non-persistent state so that the user doesn't lose what they're doing.
On 04/04/2010, at 5:05 AM, Ben Trumbull wrote: > They are not invalidated as part of Save. They are as part of Save As since > that creates a new document, with a new persistent store, a new coordinator, > new pretty much everything. Save As is creating a duplicate, so the original > content still exists. However, the UI needs to be bound to the new content. > Think of the behavior of TextEdit. Save As is like "close old, duplicate, > open new" If I was doing this just with ordinary objects, doing a Save As would not affect the objects I am working with at all. Taking the example of TextEdit, it does not lose my selection, reload my window, or lose my undo stack when I do a Save As. Logically for the user, they are still working on the same document - it just happens to be stored in a different location. If we're thinking of a layered application architecture, the physical location of the file shouldn't affect the objects at a higher layer, IMHO - but that's just philosophical discussion - I need to get to a solution for this problem. > > Yes. You cannot resurrect invalidated objects. They are toast. That's why > you're getting an exception. Nor would you want to in this case as they all > represent content from the old (closed) document not the new saved as > document. You need to toss all these references and then go through the > regular "I just opened a new document" code path for your newly saved > document to reconstruct the KVO observations. > This might be manageable to fix (but very time consuming) for instance variables, but I also have various arrays, dictionaries, array controllers etc etc that hold references to my managed objects too. I guess I really don't get the design pattern for this. Trying to keep the UI layer as separate as possible from the model, I have lots of KVO to keep the UI up to date with the changes to the data. I was not expecting to have to break those KVO connections and have to re-establish them with new objects, and am not sure what the impact of this will be, since some of them use the initial option to set up state in the non-persistent side of things. In one class, I have over 100 of these, and many other classes have quite a few that will have to be dealt with too. I'm going to have to take a good long hard look at this to see whether this is possible to do with a reasonable amount of effort in my application, or whether to ditch core data. I probably have literally hundreds of places in my application where it has references to managed objects. I had no idea this was a bad thing, and I don't recall it being mentioned anywhere in the documentation. In fact the NSPersistentDocument core data tutorial has a reference to the managed object stored in the document. I haven't actually built that entire project to see whether it would have Save As problems on the second save as or load and save as, but I guess it would. Is there some documentation somewhere on how this is supposed to be done in the architecture? Is there a working example somewhere based on NSPersistentDocument and NSAtomicStore? For me to get this far into my application development and find out that managed objects are really transient in this sense, and that I must not hold any reference to them, or if I do, make sure I can handle the need to re-fetch them in their entirety as completely new objects, and maintain the current state as far as the user is concerned...well I think I must be massively on the wrong track as far as how you should be using core data objects is concerned, and would really like to see some complete working examples of how to do this properly. > The canonical solution is to tell your controller objects like > NSArrayController to refetch from the new document. It sounds like you're > fighting the document based Save As behavior. It's "close the existing > document, save the current state to a new document, open new document" > > - Ben > I have just checked, and 26 of my nib files have array controllers in them, but I'm not sure how they are all referenced, in order to force them to reload, or how to get them to keep their selection so there is no change for the user. I don't feel that I can adequately deal with this until I understand the intended design pattern for an application based on NSPersistentDocument and NSAtomicStore, and see how the necessary updates can happen without affecting the user. TIA Gideon_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
