JSONSerializer and unsupported objects

[Sandro Martini <sa...@gmail.com>]

Hi to all,
some time ago for some tests with (Web Start) Preferences (actually in
work), i tried to serialize some objects that aren't compatible with
the JSONSerializer, like java Exceptions and (the real question of
this mail) java.util.Date ... ok, i know that this behavior is right,
because this is not specified in the json standard (i found many
articles/workaround related to json and javascript, for dates). And
the same for various Calendar types.

So my idea, on adding a sort of handlers in the Serializer (or maybe
only in the JSONSerializer) to handle a specific class, when at
serialization/deserialization an exception occurs for "object not
supported" or something like this ?
In this way, we could also ask the serializer if the given object is
"aliased" or better, "handled" in this case, and by what.
And then, we could also set if/how to handle a null instance of that
object, etc ...

To have an idea, take a look at XStream aliases mechanism:
http://xstream.codehaus.org/tutorial.html
and
http://xstream.codehaus.org/alias-tutorial.html


What do you think ?

Thanks,
Sandro

Re: JSONSerializer and unsupported objects

[Sandro Martini <sa...@gmail.com>]

Hi to all,
thanks for your feedback ...

@Christopher:
> Personally I think its over kill and makes json support not as simple as it is intended to be.
I understand your point of view, and maybe this idea could be taken
for a future release, if someone will ask to us to extend Serializers
...

> If you want to (de)serialise strongly typed objects over the wire why not use something like AMF?
Ok, you have reason, i used some time ago and was great (but from PHP
to Flash) !
For homogeneous Java environments I'd prefer some other protocols,
like transfer of Serializer objects via Serialization (in Pivot it's
the BinarySerializer class), or RMI (and a great library i used to
hide all RMI details and complexity is cajo, is really great, take a
look: https://cajo.dev.java.net/ ), or other ... .



@Greg:
> OK, how about longs, then?
OK, in my Test Application I'll make some classes to transform some
attributes (like Date in long) in domain models when
serializer/deserialized with the JSONSerializer.

> That does seem a bit complex. To me, this type of requirement implies that perhaps JSONSerializer is not the right choice for your application.
Ok ... same as what Christopher said, so same answer :-) .

But one last thing, to complete the brainstorming on this (for future
reference, or maybe for someone, to extend our Serializers):
in the Serializer i could have a Map of <Class, SerializerHandler> by
default null, and what this map is not null, if there isn't a match
for an object to serialize (or deserialize), instead of using a
toString (or throw an Exception) try if there is a match in that map
and use it, otherwise do as before ...
And the serialized version of this data could be more simple than my
idea of yesterday, tha value key as always, and in the value simple
have a json representation of that handler, like { value: ... plus
optional other values, depending on the handler } , more simple and
general than the other version, but a little more verbose.


Again, thanks to all for the feedback,
Sandro

Re: JSONSerializer and unsupported objects

[Greg Brown <gk...@mac.com>]

>> As for dates - why not just encode them as strings?
>OK, but i think that also for performance reason this should be better ...

OK, how about longs, then?

>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).

That does seem a bit complex. To me, this type of requirement implies that perhaps JSONSerializer is not the right choice for your application.

Re: JSONSerializer and unsupported objects

[Greg Brown <gk...@mac.com>]

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" <br...@brindy.org.uk> 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 <sa...@gmail.com> 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
>
>

Re: JSONSerializer and unsupported objects

[Christopher Brind <br...@brindy.org.uk>]

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 <sa...@gmail.com> 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

Re: JSONSerializer and unsupported objects

[Sandro Martini <sa...@gmail.com>]

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

Re: JSONSerializer and unsupported objects

[Greg Brown <gk...@mac.com>]

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:

Object o = null;
if (o instanceof Foo) { ... }

Even if o is declared as type Foo, this doesn't work.

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?
 
On Wednesday, April 01, 2009, at 09:16AM, "Sandro Martini" <sa...@gmail.com> wrote:
>Hi Greg,
>> There are multiple ways we could handle something like this. Can you tell us more about the specific use case(s) you are attempting to satisfy?
>for example, at server-side i have data returned from query, with
>domain objects as rows already filled (any field of those row objects
>is a standard java object, like Strings, but also Date, Calendar,
>Boolean, etc so i could also handle null values).
>
>So, instead of thinking of a convention to transfer for example Date /
>Calendar objects in json between Server and Clients (and the opposite)
>I'd like to configure the related Serializer with a specific behavior.
>
>But maybe as you said there are more solutions ... can you tell me some hints ?
>
>Tell me if is not clear.
>
>Thanks a lot,
>Sandro
>
>

Re: JSONSerializer and unsupported objects

[Sandro Martini <sa...@gmail.com>]

Hi Greg,
> There are multiple ways we could handle something like this. Can you tell us more about the specific use case(s) you are attempting to satisfy?
for example, at server-side i have data returned from query, with
domain objects as rows already filled (any field of those row objects
is a standard java object, like Strings, but also Date, Calendar,
Boolean, etc so i could also handle null values).

So, instead of thinking of a convention to transfer for example Date /
Calendar objects in json between Server and Clients (and the opposite)
I'd like to configure the related Serializer with a specific behavior.

But maybe as you said there are more solutions ... can you tell me some hints ?

Tell me if is not clear.

Thanks a lot,
Sandro

Re: JSONSerializer and unsupported objects

[Greg Brown <gk...@mac.com>]

There are multiple ways we could handle something like this. Can you tell us more about the specific use case(s) you are attempting to satisfy?
 
On Wednesday, April 01, 2009, at 08:03AM, "Sandro Martini" <sa...@gmail.com> wrote:
>Hi to all,
>some time ago for some tests with (Web Start) Preferences (actually in
>work), i tried to serialize some objects that aren't compatible with
>the JSONSerializer, like java Exceptions and (the real question of
>this mail) java.util.Date ... ok, i know that this behavior is right,
>because this is not specified in the json standard (i found many
>articles/workaround related to json and javascript, for dates). And
>the same for various Calendar types.
>
>So my idea, on adding a sort of handlers in the Serializer (or maybe
>only in the JSONSerializer) to handle a specific class, when at
>serialization/deserialization an exception occurs for "object not
>supported" or something like this ?
>In this way, we could also ask the serializer if the given object is
>"aliased" or better, "handled" in this case, and by what.
>And then, we could also set if/how to handle a null instance of that
>object, etc ...
>
>To have an idea, take a look at XStream aliases mechanism:
>http://xstream.codehaus.org/tutorial.html
>and
>http://xstream.codehaus.org/alias-tutorial.html
>
>
>What do you think ?
>
>Thanks,
>Sandro
>
>