Re: Deserializers for NSArray, NSDictionary
Re: Deserializers for NSArray, NSDictionary
- Subject: Re: Deserializers for NSArray, NSDictionary
- From: Mike Schrag <email@hidden>
- Date: Wed, 24 May 2006 16:30:22 -0400
A little extra digging reveals that
QName EOGLOBALID_QNAME_WEBSERVICESCORE_WORKAROUND = new QName
(SOAP_URI, "Dictionary");
and
typemapping.register(com.webobjects.eocontrol.EOGlobalID.class,
WOSoapConstants.EOGLOBALID_QNAME_WEBSERVICESCORE_WORKAROUND, new
WOGlobalIDSerializerFactory(), new WOGlobalIDDeserializerFactory());
typemapping.register(com.webobjects.foundation.NSDictionary.class,
Constants.SOAP_MAP, new WODictionarySerializerFactory(), null);
So NSDictionary maps to the normal soap map definition and presumably
you can WOWebServiceRegistrar.registerFactoriesForClassWithQName map
your own definition of EOGLOBALID_QNAME_WEBSERVICESCORE_WORKAROUND to
be NSDictionary instead as well? Obviously you're going to probably
have issues with sending around globalids like Andrew mentioned.
ms
On May 24, 2006, at 3:51 PM, email@hidden wrote:
Hello Frank;
I've been playing in this area recently and am happy to say I've
pretty much figured out how to achieve what I need in a robust
manner and I hope to write the information up in the coming
months. There are some tricky things. The first of which is that
the NSDictionary in the Cocoa environment appears to deserialise on
the WO end as an EOGlobalID. This is in fact what I actually do
want, but if you don't want this, I am not entirely sure how to end
up with NSDictionaries. I notice that there is a constant:
WOSoapConstants.
EOGLOBALID_QNAME_WEBSERVICESCORE_WORKAROUND
..but as this is undocumented, I can't see how it comes into play
and if it would help matters or not. I wonder if there is a means
by which you can remove the 'WOGlobalIDDeserializer' from the WO
end and put your own deserialiser in or perhaps (I guess) the J2SE
collection classes are handled out of the box? There is a list of
WO-type serialisers and deserialisers in the package:
com.webobjects.webservices.support.xml
I also found that the 'multiref'-s generated by AXIS in responses
were causing trouble in the WebServicesCore deserialisers and I had
to turn this off in the 'server.wsdd' file in the WO project.
Another tricky thing is the serialisation of NULL/nil/NSNull from
the Cocoa end was problematic as well because it lacked knowledge
of the target parameter type. I got around this by writing my own
deserialiser at the WO end to cope with these type-less NULL's.
I'd be happy to send you a copy of this if you want to mail me off-
list.
It would be fab if Apple could take a look at Cocoa/WO web services
integration and better document or resolve these issues as there
are a number of people asking about this on the list in the past
months and Cocoa is an obvious client technology for people working
with WebObjects.
cheers.
I'm trying to build a WO web services application with a Cocoa
client. I pass the data from the server to the client as an NSArray
of NSDictionaries, which works fine. The same approach fails from the
client to the server because, as I guess, the NSArray and
NSDictionary classes do not have deserializers registered. Is there a
workaround for this? Could I somehow create the deserializers by
myself?
___
Andrew Lindesay
www.lindesay.co.nz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mdimension.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden