Storing generic objects as plists (i.e. plist object persistence)
Storing generic objects as plists (i.e. plist object persistence)
- Subject: Storing generic objects as plists (i.e. plist object persistence)
- From: email@hidden
- Date: Thu, 27 Jun 2002 12:43:23 -0500
I'm going to try to send this again .. even I didn't see it come in the
first time around and I would
think this is an "interesting" topic.. (IMHO anyway! :-)
I did do a little experiment with #2 below and although it did produce
some interesting
data, it wasn't plist XML in the resulting file, but rather binary
data.. so still not what I want..
Anyone have some ideas on this?? Anyone?? Buehler?? :-)
TIA!
-Steve
On Wednesday, June 26, 2002, at 03:40 PM, email@hidden wrote:
>
Hi all..
>
>
Again looking to see if there is a "agreed" on best practices method
>
for this..
>
>
As is normal in such things, I have expanded the data I want to store
>
for a document..
>
Specifically I want to track and store a sort of "table of contents"..
>
but a "tree" like TOC..
>
In any event, I created a nice little class called TOC which has as its
>
"ivars" simple
>
types like NSString's and a NSMutableArray which will itself contain
>
objects of class "TOC".
>
>
So far so good.. except when it comes to storing and retrieving the
>
document data! :-(
>
>
Following the Vermont Recipe model I wrote the "dictionary" routines
>
and do a dictionary
>
writeToFile to get a nice XML Property list..
>
>
Well, as we all know.. even though the TOC class itself contains
>
nothing but basic structures
>
NSDictionary does like, NSDictionary itself does not deal with a type
>
of "TOC" and didn't write
>
anything out for that entry ..
>
>
The question: What is the "best" way to handle application objects and
>
save them in plist
>
format ?? Can it be done?
>
>
I have read a couple of articles and the Sketch example.. It appears
>
that I can
>
>
1) Use NSArchiver on my object to create a NSData object which IS
>
writable.. (but does it really give me
>
a good way to "edit" what in turn is nothing but NSStrings and a
>
NSArray??)
>
>
2) Use some "interesting" code "somehow" that allows one to use the CF
>
routines for XML thusly:
>
>
@interface NSObject (xmlConverter)
>
- (NSData *)xmlPropertyListData;
>
@end
>
>
@implementation NSObject (xmlConverter)
>
- (NSData *)xmlPropertyListData
>
{
>
return [(NSData *)CFPropertyListCreateXMLData(kCFAllocatorDefault,
>
(CFPropertyListRef)self) autorelease];
>
}
>
@end
>
>
Now, I can keep the Document-based app method I use and I do not need to
>
use writeToFile:atomically and rewrite my app (commented out is what I
>
used to do):
>
>
- (NSData *)dataRepresentationOfType:(NSString *)type {
>
if ([type isEqualToString:GWCCDocumentType]) {
>
// NSString *string = [_job description];
>
// return [string dataUsingEncoding:NSASCIIStringEncoding];
>
return [_job xmlPropertyListData];
>
} else {
>
return nil;
>
}
>
}
>
>
THE ABOVE WAS HAPPILY STOLEN FROM THE ARCHIVE SITE...
>
>
So I wonder if over the past year if a concensus has occurred as to the
>
best way to store
>
this type of data? (Remember the data is sort of recursive in nature
>
being a tree) ..
>
>
Thanks all!
>
>
-Steve
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.