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
