using NSDocument w/ autosaves is a great way to go—lots of bang for your buck! xml could open possibilities in terms of web potential. moving history into your model will better facilitate portability [in case you’re thinking in this direction].
all good things for a cad app. On Apr 8, 2014, at 6:24 PM, Rick Mann <rm...@latencyzero.com> wrote: > Well, one of the issues is the data types. It's a bit clunky, but workable. > There's one type of entity I want to create, a "Properties" table that maps > strings to arbitrary value types. This would be trivial if I managed it > myself, but Core Data doesn't let me have an entity attribute of type id, > AFAIK. The other problem I'm facing, which is probably due to me > misunderstanding NSPersistentDocument, is that I want my Library document to > always autosave (in the sense that it programmatically saves after changes > like adding a new Part object, rather than presenting the user with a save > sheet). I haven't quite figured out how to do this. There are the saveToURL: > methods, but what URL? It was opened from a file, it should know that. I just > want to persist changes and clear the dirty state. Maybe I'd have the same > issues with a "regular" NSDocument. > > The other thing (I meant to mention in the original email) is that I can't > take advantage of autosave and async file operations, etc. > > BUT: Do I lose a lot of undo support? I've never tried to implement undo > without Core Data. > > On Apr 8, 2014, at 15:15 , Mike Manzano <m...@instantvoodoomagic.com> wrote: > >> Depends. Why are you “fighting” Core Data? >> >> Mike >> >> >> >> On Apr 8, 2014, 3:13:12 PM, Rick Mann <rm...@latencyzero.com> wrote: >> This may prove to be an unproductive question to pose, so I apologize in >> advance. >> >> I'm generally a big fan of Core Data, but I'm developing a moderately >> complicated CAD app with libraries and design documents and such, and >> beginning to wonder if it would be easier to do if I weren't fighting Core >> Data. I'm wondering what the tradeoffs might be. >> >> If I were to dump Core Data, I'd keep the entire object graph in memory all >> the time, writing it out completely each time. I'd probably write XML, or >> some other text-based format (as much as I abhor text-based formats) because >> of the ease in diffing changes and using it with source control. >> >> As I write this, I realize that I can't just keep a whole document in >> memory; the library (which would be a collection of separate files on disk, >> but presented as a unified collection of content in the UI) could be very >> large and I'd rather not load in the whole thing. Nevertheless, I think >> that's doable. >> >> I'd have to handle relationships myself, but all the data types become >> easier to manage (I use a lot of C structs, well, really C++ structs). >> >> Thoughts? Thanks! >> >> -- >> Rick >> >> >> >> - signature.asc, 211 bytes >> _______________________________________________ >> >> 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: >> https://lists.apple.com/mailman/options/cocoa-dev/mike%40instantvoodoomagic.com >> >> This email sent to m...@instantvoodoomagic.com > > > -- > Rick > > > > _______________________________________________ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/etaffel%40me.com > > This email sent to etaf...@me.com _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
