Some serializers do support customization. For example, CSVSerializer
lets the caller specify the class of the item that will be used to
contain the deserialized row data. Others, such as JSONSerializer, do
not - JSON is hierarchical and doesn't support a means of specifying
an expected structure. Without that, it would be difficult to say
that, for example, a node 3 levels down at a given path should be
deserialized using MyMapClass vs. HashMap.
On Jun 24, 2009, at 4:24 AM, Sandro Martini wrote:
Hi Niclas,
i think this is because of the Serializers approach, with all
serialization details inside, and to ensure that none can transfer
object instances where not wanted (for example GUI elements).
The problem could be with objects that are not directly supported by
Serializers (some time ago i had a discussion with the team, but my
proposal to generalize things has been rejected :(- because some
things would be more complicated than current).
Maybe in this case we could think to use some way to do this using
introspection (for example for beans), or other approach ... Greg can
tell if some other is already available.
Otherwise i could propose (another time) my old proposal to set
optional handlers inside Serializers, and let developers handle custom
objects inside some of them ... tell me if you like this.
For example, is JSONSerializer there is nothing that handle Date
objects (because in JSON specifications they aren't handles, a flaw in
the spec, in my opinion) and currently the developer has to handle
this otherwise an Exception will be thrown.
With my proposal with serializer handlers, the default if the same,
but if i put a dedicated handler, this could be transparent ...
What do you think ?
Bye,
Sandro
