A Quest for Better Json

We use json for the ajax call in NEMA DIY. And it is an interesting journey for us to find a way to implement it.

For my last project, I used a small xml java generating library for AJAX. This time, we need to generate more and we need json instead. (Amit likes Json more.) In the very beginning, we rolled our own and use some library (XStream I think) to write directly to HttpServletResponse. After a while, it becomes quite tedious, so I looked around and find Spring-Json. It is kind of nice to use with Spring MVC, I only need to register a special view for Json and push models in the same view as the normal jstl/jsp way. We are happy for a couple of months.

We upgraded to Spring 3 in May and Amit switch to the Jackson Json view that bundled with Spring 3. It works in the same way as Spring-Json because Spring-json is based on Spring 2.5. But we met some problems soon. Jackson does not handle the circular reference very well. Spring-json's default engine SOJO simply break the reference in some level and that serves us well enough. Jackson can works with proper annotation in this situation but we do not like to modify the code for this purpose and furthermore, we might need two different versions of Json serialization for the same class. So I have to reinstate spring-json and puts lot of exclusion in the maven dependency description.

We are not very satisfied with the situation, especially Amit. He does not like spring-json because its dependency on spring 2.5, which might break down with our majorly spring 3 stuff. But he has to live with it as I am the guy doing the front-end now. But deep down, I am a little uncomfortable with it either. All these tools are a little over-engineering for us because they are designed for bi-direction purpose that supports both serialization and de-serialization. But we only need simple serialization in Java and deserialization happens in Javascript. While we do have some very complicated classes that needs to be sent via json, we only need part of the information, which can be in a fairly simple form, not the complicated model that those framework engineered for.

I started to look into Dojo and would like to switch to its datagrid. It can hook with its data stores and their reference store is Json one. Their documents are limited and little weird. I made some experiments and it seems that the dadagrid only handles the array of flat json objects. So I am back to square one and has to work on the json presentation. I tried to work within spring-json to filter out some more complicated but not useful. Not working! So back to XStream. It is hard. I tried several things, even looked into its source. That is an interesting story by itself. Now I back to write to response directly. I ended up wrote some customized converter to plug-in for certain types.

And it breaks down when I tried to write two or more models once. I just cannot get it work. (From the hindsight, I might be able to do it by push it as Map<Spring,Object>. Well, I tested it and it does not worked out well. ) Finally, I have to try the jsnoview. Now I decide to do some really basic thing. I push the object in as a Map<String,String>, and array as the list of it. it works just fine with jsonview. Actually it works better because now I can push in a processed value instead of the raw value to be processed in javascript. It occurs to me that maybe the Jackson json works with it as well. I tested it and it works just fine. Now we are using Jackson view and home-made pre-processing. Evething seems to work. I am fairly happy.

I guess the moral of it is that sometimes it is better to just do it by myself and it might be the simplest approach. I spent maybe 50hrs on the source, document of xstream, spring-json and it is kind of wasted. They are good for what they are set to do, but their focus often do not align with mine well and therefore hard to use. Next time looks out!

What a journey!