Re: Subclassing NSCoder
Re: Subclassing NSCoder
- Subject: Re: Subclassing NSCoder
- From: Meik Schuetz <email@hidden>
- Date: Sun, 31 Aug 2008 20:03:01 +0100
Dear Michael,
thank you very much for your valuable information - I definitively
will have a look at your MAKeyedArchiver, just to learn how it's done.
The idea of implementing the xmlRespresentation methods is just great
and serves perfectly.
Once again, thanks a lot for your time.
Best regards
Meik
On Aug 31, 2008, at 6:30 PM, Michael Ash wrote:
On Sun, Aug 31, 2008 at 11:45 AM, Meik Schuetz <email@hidden>
wrote:
Dear everyone,
I am trying to create my own NSCoder implementation to serialize
objects to
a XML format which would like to use to communicate with WCF
service. The
serialization is already done and I had no problems do it, however
I've got
some conceptional questions about the de-serialization:
Given the serialized XML:
<EntityKey>
<stringValue>HELLO WORLD</stringValue>
<boolValue>True</boolValue>
<intValue>12</intValue>
<compositeValue>
<stringValue>THIS IS THE SECOND INSTANCE</stringValue>
<boolValue>False</boolValue>
<intValue>4711</intValue>
<compositeValue></compositeValue>
<arrayOfString><Value>1</Value>
<Value>2</Value>
<Value>3</Value>
</arrayOfString>
</compositeValue>
<arrayOfString><Value>1</Value>
<Value>2</Value>
<Value>3</Value>
</arrayOfString>
</EntityKey>
How would you de-serialize the node <CompositeValue> (which is a
composite
value of type CompositeType, having the attributes stringValue,
boolValue,
intValue, compositeValue and arrayOfString)?
1) Would you store information about the type in the XML and let the
NSCoding subclass have the intelligence to create and initialize
the object
(ex. via NSClassFromString)?
2) Or would you place this intelligence in the entity object's
:initWithCoder? If so, how would you create and initialize the
composite
object passing the Coder reference?
You have to store type information in the XML. There's no other place
for you to get it. You can't make that decision in -initWithCoder:,
because -initWithCoder: supposes that you have *already* discovered
the type and allocated an instance of the class in question. It's like
trying to find your friend's phone number by calling him to ask him
what it is.
That said, I'm not sure that NSCoder is a good API for you to use for
this in any case. Your XML looks like it's a typical XML document,
with a tree structure of fairly regular values. NSCoder is an API for
encoding arbitrary object graphs, which can include disconnected sets,
multiple references to a single object, and even cycles. It can encode
arbitrary objects, arbitrary data for those objects, and arbitrary
relationships between them.
NSKeyedArchiver can already produce XML. If you look at it, you'll
find that it's very confusing. This is because of all the features it
supports. Since XML is a tree structure, it has to do some fancy
things to support arbitrary relationships.
So if not NSCoder, then what? I'd suggest a simpler custom API, such
as a general understanding that your classes will implement a
-xmlRepresentation and -initWithXMLRepresentation: method pair,
possibly creating and using NSXMLNode instances. This would allow you
to create and decode XML without needing to go through an NSCoder.
If you still do want to create an NSCoder subclass, then you might
find mine helpful as some sort of guide. It's called MAKeyedArchiver
and you can download it here:
http://www.mikeash.com/?page=software/source.html
It's intended to be a general-purpose archiver which writes to a
custom binary file format, but you may (or may not) find its general
design and approaches to be useful.
If you do take a look at it, you should beware that I wrote it at a
time when I was sure that the PowerPC 32-bit architecture was
immortal, so the code makes a lot of bad assumptions about the size
and endianness of basic data types. It should work fine on i386, but
the archives won't be cross-architecture compatible. It will probably
crash on PPC64 or x86-64.
The need for MAKeyedArchiver has pretty much gone away, since Cocoa's
built-in archivers have gotten a lot faster than they were when I
wrote it. But just in case anyone happens to have a burning desire to
fix the deficiencies I mentioned above, patches are welcome.
_______________________________________________
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
_______________________________________________
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