On 16/12/2009, at 5:12 PM, Richard Somers wrote: > On Dec 15, 2009, at 10:06 PM, Graham Cox wrote: > >> You're creating an archive-within-an-archive and an archive is just a block >> of binary data by default. If you set the output format type of your >> secondary archive to XML, you'll be able to see the keys, but it will still >> be a separate second archive within the main one. > > Thanks for the clarification but I do not fully understand part of your > comment. The value of 'foo' comes into -(id)transformedValue:(id)value as a > NSConcreteValue instance. The frameworks automatically wrap it thus. In my > new implementation of this method I get the value of 'foo' back into a struct > and encode with the keyed archiver. It is then sent out as NSData (thanks to > your corrections) archived only a single time directly from the struct. So > just a single archive is sent into the Core Data store. So I don't understand > what you mean by an archive-within-an-archive. Sorry if this is a dumb > question.
Ah, I think I'd misunderstood something - I thought you were archiving a bunch of objects for file saving, which would not archive your struct, so you were archiving the struct to a separate piece of data which could be archived. Hence archive-within-an-archive. What you actually have is an archive-within-a-core-data-store. I don't have any experience of Core Data so I don't know how it represents itself on disk, but I sort of gather that it will use one of: sqlite store, archive (binary) or archive (XML). If either of the latter you do have an archive-within-an-archive, it's just that the main archive is built and written by Core Data. > I was trying to emulate what Apple does with NSRect, NSSize, NSPoint, etc. I > thought if Apple can get the Cocoa frameworks to work with simple structs > then why can't I. Because there are special conversion functions such as NSStringFromRect(), etc which are used when archiving, so in fact the structs are stored as strings. > My struct 'Foo' really wants to be a struct not a class, I think. It is used > in a lot of heavy duty math calculations and functions but I also need to > save it to the persistent store. Making it an object wouldn't necessarily impact on that. You could return the struct itself as a property or just implement the math as methods of the Foo class. But it's up to you - as a naked struct it will be a poor cousin to a first-class object when it comes to all sorts of handy things, such as memory management, collections and archiving. > Perhaps I should try using two attributes, one transient and the other a > "shadow" representation. The documentation for 10.5 seems to favor > transformable attributes for non-standard persistent attributes. I was > initially successful using a transformable attribute with a simple custom > value transformer using NSArchiver so I thought I was on the right track. > Every thing worked but the save document as binary. Well, I can't help there - this is in the realms of Core Data which I haven't got any experience of. There are likely others who can chip in on this point. --Graham _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
