JSON deserialization into custom beans

[dma]

We're considering removing the support for deserializing JSON into custom classes because it may be more practical to deal with basic JSON representations (null, String, Number, Boolean, JSONObject, JSONArray). If you are using this functionality, please speak now or forever hold your peace! :)

[barcia]

We're considering removing the support for deserializing JSON into custom classes because it may be more practical to deal with basic JSON representations (null, String, Number, Boolean, JSONObject, JSONArray). If you are using this functionality, please speak now or forever hold your peace! :)

I think we need to keep this. Especially for those who like some sort of domain model (especially in lite of some persistence enhancements that may be coming?)

[steveims]

I think we need to keep this. Especially for those who like some sort of domain model (especially in lite of some persistence enhancements that may be coming?)

If you're referring to the lightweight resource modeling work, then custom classes are not needed for deserialization. The resource modeling uses "value objects" (think Maps) as in-memory representations.

[pmuellr]

Classes can provide a nice structured way of describing ... structure. Something lacking when the story is "your objects are bags of goo" (maps of arrays of maps of ...). Classes are also nice if you're interfacing to existing Java code. A lot of Java code doesn't handle bags of goo very well.

[barcia]

I think we need to keep this. Especially for those who like some sort of domain model (especially in lite of some persistence enhancements that may be coming?)

If you're referring to the lightweight resource modeling work, then custom classes are not needed for deserialization. The resource modeling uses "value objects" (think Maps) as in-memory representations.

Ok. I agree with Pat. If someone pulls in Hibernate or JPA for example, you can still provide value. Why do you want to get rid of them. The JSON API's do not seem bloated.

[dma]

Ok. I agree with Pat. If someone pulls in Hibernate or JPA for example, you can still provide value. Why do you want to get rid of them. The JSON API's do not seem bloated.

The goal here is consistency. Currently, we have JSON de/serializers [JsonToObject and ObjectToJson classes, respectively]. For XML, we provide a serializer [ObjectToXml] and recommend using Groovy's XMLSlurper for the reverse function. If we keep the JSON -> Object support, it seems fitting to have Zero mechanism for XML -> Object. Thoughts?

Additionally, I wanted to aptly repackage the Converter [zero.json.converters.*] code when implementing bug 1291. I planned to use ‘serialization’ in the package for clarity [zero.serialization.*].

[pmuellr]

JSON and XML are so wildly different that I don't know that complete consistency makes sense.

My personal feeling is that converting between 'objects' and JSON is typically pretty straight-forward; both JSON and the languages we typically use 'speak the same language' - primitive types (strings, integers, etc), and some simple composition operators (lists, maps/objects). The same isn't really true for XML - there is no 'standard' way to represent a list; rather there are a multitude of ways to represent a list. And viewing your XML with data types in mind involves looking at a schema to figure out what the 'type' of that element or text content is. An additional complication.

One of the lessons I took away from my few, short weeks of playing with WSDL, is that you really don't want to be designing your XML to be the output of some programming-language-X-to-XML translation. The result will be quite distasteful. It will also likely be pushing the bounds of the agreed semantics of XML schema. Better, is to design your XML as an XML document. That's your API. The XML. When you get it the way you want it, THEN figure out how you're going to represent it in objects / data structures in programming language x.

So, personally, I don't believe we should be in the business of providing object -> XML mappings, or XML -> object mappings, at all. At least, automated versions of them. If you want to framework-ize it, so I can create converters myself, register them, and have you run them on my behalf when I call a convert*() method, then great.

Automated (but still customizable) converters for JSON seems like it makes sense to me.

[dma]

I understand that JSON and XML are different, however, that doesn't mean that we shouldn't be symmetrical with our support. Converting Objects to XML could be handy for someone who doesn't want to deal with any XML APIs when building an app [prototype, sample, etc.] using Zero.

[barcia]

I understand that JSON and XML are different, however, that doesn't mean that we shouldn't be symmetrical with our support. Converting Objects to XML could be handy for someone who doesn't want to deal with any XML APIs when building an app [prototype, sample, etc.] using Zero.

I agree with this, providing a default is always good. This is the same reason I want to keep the custom classes for JSON. If I bring my own data model into an app, I can easily expose it.

[dma]

Let's just leave well enough alone then. If anyone has any more input, please respond to this post or add a comment to bug 1291.