Re: Reading unknown class from NSKeyedUnarchiver
Re: Reading unknown class from NSKeyedUnarchiver
- Subject: Re: Reading unknown class from NSKeyedUnarchiver
- From: Adrian Ruigrok <email@hidden>
- Date: Wed, 8 Mar 2006 09:31:43 -0800
Thanks Mike,
Certainly, and adding a level of indirection is exactly how I planned
to skin this one if I could not find a way around it at read time. I
had hoped to come up with a solution that was independent entirely on
the encoder. It seems like a common enough problem of handling an
archive that has classes you don't know about at the moment. Seems
you should be able to ask the keyed unarchiver for an object as a
block of data, or query its keys without having to know what they
are. But as nobody else seems to have any insight I will fall back to
handling it myself.
Thx again!
Adrian
But it would seem I have to deal with the problem myself
On 7-Mar-06, at 1:57 PM, Mike Blaguszewski wrote:
On Mar 7, 2006, at 3:42 PM, Adrian Ruigrok wrote:
We support 3rd party plug-ins, and it is quite possible at runtime
that we are reading an NSView subclass without having the plug-in
loaded. I want to be able to read the data from the unknown class,
and ferret that data away so that when I write out my views I can
re-save it to my document and then at a later time if the document
is opened with the plug-in loaded everything will still be there.
Maybe I'm missing something, but couldn't you add a level of
indirection here? Archive the plugin-dependent data into an NSData
object, then archive that into the rest of your object graph. That
way, it really is a bundle of bits unless you take the step of
explicitly unpacking it. But it won't prevent you from unarchiving
anything else. I think the NSCoding protocol is probably flexible
enough to do this pretty transparently.
--
Mike Blaguszewski / Ambrosia Software, Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden