JSON is nice when your service may also be consumed by clients that are not AMF-capable.
However, if you do need strong typing and don't mind being Java-specific, you could use BinarySerializer. On Wednesday, April 01, 2009, at 12:14PM, "Christopher Brind" <[email protected]> wrote: >Personally I think its over kill and makes json support not as simple >as it is intended to be. >If you want to (de)serialise strongly typed objects over the wire why >not use something like AMF? Since it is binary it is much more >effecient than json, and there are plenty of libraries around for it. >Though of course you lose human readability and simplicity, but that's >swings and roundabouts for you. > >Cheers >Chris > > >On 01/04/2009, Sandro Martini <[email protected]> wrote: >> Hi Greg, >>> I don't think we have much control over null values. As far as I know, >>> null is null - can't get any other information about it; i.e. this >>> conditional will always return false: >> Ok, excuse me, it was re.thinking at something as i had in some >> particular situations (where i needed to transform a particular >> instance of a class into null or a marker for null, and the opposite >> ... for example do you remember by BinarySerializerEnhanced of many >> months ago ?), but here you can ignore this. >> >>> But null is a supported JSON type, so this shouldn't really be an issue. >>> As for dates - why not just encode them as strings? >> OK, but i think that also for performance reason this should be better ... >> Then, my idea if for a more general way to handle anything not >> directly supported by the Serializer, but i understand that this could >> add more complexity than benefits, at least at the moment ... because >> in some cases this could lead to bad >> >> So at concept level, if i could attach optional handlers (my classes >> extending a base Pivot class or interface for this) for >> serializing/deserializing some my classes, i could give to the >> serializer the real data without making conversions (that would be >> done by handlers inside the Serializer and only if enabled and for >> example after an exception). >> >> For example, as a sample, we could implement a sample >> SerializerHandler/Transformer (mhhh it's better another name i think) >> and (but only when added the an instance of JSONSerializer) trying to >> convert a date object value into a form like >> "handler-full-class-name:1234567890" where the value is for example to >> toMillis() value, that's more efficient of the toString when generated >> and the parse when read ... >> Mhhh now i think that reading a json (well-formed, ok) with this info >> inside would be not so simple (and processing this value by the >> related handler), suggestions ? >> >> After this, what do you think ? >> If you what i could try to implement a simple version of this (after >> finishing the other stuff i have ... but for example on the >> Persistence I'd like some feedback) ... tell me. >> >> >> Oh, if other Pivot Developers have ideas/suggestions, are welcome, as >> always. >> >> Thanks again, >> Sandro >> > >-- >Sent from my mobile device > >
