XStream Map<String,Ojbect> is not a good idea for Multi-Models

I guessed in an earlier post that I might be able to get multi-model work with XStream using a Map<String,Ojbect>. Well, it does not work well. The ending result is something like

{"map":
[{"entry":[
{"string":"jobs","list":[""]}, {"string":"head","org.imirsel.nema.flowservice.config.SimpleMeandreServerProxyConfig": {"host":"nema.lis.uiuc.edu","port":11714,"maxConcurrentJobs":1,"username":"admin","password":"admin"}},
{"string":"workers","map":[{"entry":"org.imirsel.nema.flowservice.config.SimpleMeandreServerProxyConfig":{"host":"nema-c-1-2","port":11714,"maxConcurrentJobs":2,"username":"admin","password":"admin"},"org.imirsel.nema.flowservice.config.MeandreServerProxyStatus":{"numRunning":0,"numAborting":0}}}]}]}]}

Not nice. It is possible in javacript, but will need quite some codes to handle. Still, I would like to stick with something required minimal massaging in javascript side. Mine current solution seems better.

Spring Webflow

I have been using it for maybe two months and probably can say a little about it now. It is not our first choice. That would be GWT. We started NEMA mostly with the traditional Spring MVC. Amit, the leading programmer in NEMA, familiar with it, although he leaved the binding/command part out of the picture. So we used it kind of strictly of MVC model. I did not use spring mvc before, but I used Struts 1 and Spring in last project and the concepts of MVC and Inverse of Control (IoC) is not unfamiliar. I mostly do the patching work for Amit, adding a new controller, modify the existing one, etc.

Later, we need a more wizard like function, and Amit envision a site with more Ajax-like functions, such as status bar, ... So he asked me to look into GWT. But I am not familiar with it and things get bogged down as I learned it. Mostly, I felt a bit uncomfortable with GWT because it lacks the mature frame work like Spring MVC, everything backs to JSP/servlet stage. Also, it depends on CSS heavily and none of us are comfortable with it. But if it is now, I might stick longer and be more patient with it and maybe we should use it. Anyway, we cut it loose and here comes Spring Webflow.

The other senior programmer, Andrew used webflow before and he likes it. So we adopted it for its natural fit for wizard function. And in some sense, we just want to try a new tool. The webflow journey started.

It is fun experience with it. A little rough at the beginning, the first few weeks I always feel close, but something keeps popping up. Amit was kind of pissed off by my promising and not delivering. But finally, we delivered. And now it works fairly well.

A few things that I would like to say about spring webflow:

• It can use the POJO as actions, which makes me feel better and excellent for testing. Webflow provides quite some convenience to facilitate this. I rely heavily on POJO and shift quite some logic into the webflow definition. This makes the definition a bit clumsy, but it is probably a good price to pay.
  
• The history function does not work from suflow. See my post in their forum. Spring forum is kind of frustrating. No reply, even no view.
  
• Some small things that are not well-documented. Amit upgraded it to 2.1.0Milestone and does not tell me. It switched to Spring EL where it uses #() instead of $(). I dig around quite a while to figure it out.
  

It also comes a Spring JS by default bundled with Dojo, which is part of the reason I started Dojo. I am going to look into it.

Programming

I did a lot of programing recently as RA for the NEMA project. And I like it. I don't know, but I can work on it all day without checking any fun sites, deal sites, news, or even emails. Maybe deep down I like programing more? I do not know. Maybe it is just something that I feel fairly confident with and comfortable to work with.

I like programming. A computer is faithful and responsive. You put something in and it spits out according to it with no surprise. Well, there are plenty of surprise, or not-saying from computer, but after some working, debugging, they becomes reasonable. That is one reason I like programming and the one I often tell people. I am not sure whether there are deeper one. There might. I cannot speak out it clearly. So here it is.

A Good Site for This Blog--Escaping HTML

It is quite irritating to find all the < ... > go away in this blog, it takes them as tag. I have to escape them. When you get to code, xml or java generics, where there are lots of them, it becomes pain in ***. A quick google gives me a useful page that does it for me. Thanks.

Command Pattern and Generics in Java - JSON Story (3)

So what I want to do is to put a list of the same objects into List<Map<String,String>>. I created some converters for convert single object into <Map<String,String>>;. When I start to write the list converter, I realize that I only need a generic one and use the command pattern.
Here is the list converter:

public class ConverterToList<T> {



 public List<Map<String,String>> convertToList(Collection<T> collection, ConverterToMap<T> converter){
  
  List<Map<String,String>> list=new ArrayList<Map<String,String>>();
  for (T t:collection){
   list.add(converter.convertToMap(t));
  }
  return list;
 }

}

And the interface for command

public interface ConverterToMap<T> {
 
 public Map<String,String> convertToMap(T t);
 
}

A sample implementation

public class ConverterToMapJob implements ConverterToMap<Job> {

 @Override
 public Map<String, String> convertToMap(Job job) {
  Map<String, String> map = new HashMap<String, String>();

  JsonHelper helper = new JsonHelper(map);

  helper.addCheckNull(job.getId(), "id");

  helper.addCheckNull(job.getSubmitTimestamp(), "submitTimestamp");
  helper.addCheckNull(job.getScheduleTimestamp(), "scheduleTimestamp");
  helper.addCheckNull(job.getEndTimestamp(), "endTimestamp");
  helper.addCheckNull(job.getUpdateTimestamp(), "updateTimestamp");
  helper.addCheckNull(job.getHost(), "host");
  helper.addCheckNull(job.getName(), "name");
  helper.addCheckNull(job.getPort(), "port");
               //now I am free to put any bean. Even not a bean. 
  helper.addCheckNull(job.getJobStatus(), "status");
  return map;
 }

}

I am fairly happy with this. This structure only handles a flat object or an array of it, and not general enough for more complex multi-level objects. But that fits my needs now and in the foreesable future of this project. I probably will hang with it and leave the json problem in my back. It is generally not a good idea to reinvent the wheel, but when the wheel is too complicated for your car, maybe it is better to roll your own.

XStream - Json story (2)

Now I understand xstream much better after study their codes for maybe 20-30 hours. It is nice, but probably overkill for my purpose. Their documentation is good enough to get you going. But there are lots of more intricate that might be good to write.

One problems with XStream is that it is really designed for xml. For xml, it is fine to have something like


<birthday type="java.sql.Timestamp">
12-20-2004
<birthday>

It would be whole lots more complicated for json. Their solution (xstream 1.3.1, both jettison and there own driver) is

birthday:{
@class:java.sql.Timestamp,
$:12-20-2004
}

For my purpose, I only need the value, not the class information. I understand that it is useful information when you need to deserialize the json back into a java object. I have a object with type java.util.Date, with a value as java.sql.Timestamp, which is a subclass of java.util.Date. And xstream keeps spit out things like the above, while I only need a simple things like birthday:12-20-2004. When the object is really just a java.util.Date, and xstream generates the simple thing. These inconsistency completely messed up my code. I need a fairly complicated javascript code to handle the situation like such, while things are much easier to handle if xstream always convert it into the simple case. I tried all kinds of way to get around it but no luck. I looked into their engine, but it is quite complicated and I did not fully get it. And furthermore, their code (at least json driver) is under heavy development. I wa confused at first by very different code for the same class and finally realized that the eclipse show the jave source from maven repository (official 1.3.1 release) and I got the 1.3.1 developing trunk. Man, they are very different and it seems they are trying something quite different. Back to the topic,
I tried to register the the Date converter for java.sql.Timestamp.class and it does not work. Finally I found the way to work:

xstream.addDefaultImplementation(Date.class,java.sql.Timestamp.class);

Frankly, I do not quite get why it works. And this add some discomforting.

Another not-so-nice thing about xstream is that it does the reflection on fields only, not the common bean convention. So some fake beans does not get converted. I wrote a couple of converter for complex classes I have. And that is much easier to write it than to looking through all the source and documentation.

But the final problem comes with the multiple models. XStream can only do one at a time. So I give up and goes to the original approach and as I explain in the last post, things work out pretty well.

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!

Nightmare of CSS,mesh

CSS is evil!

It is powerful, but confusing as hell! I added Dojo datagrid to some pages, but often things screw up. There are so many similar different styles in css, and there are no error messages when you have a typo or wrong tag. And there are too many things to learn, too many tricks. Especially when I works with the established css setting for our nema.

Coupled with the sitemesh in our project, css can do even more damage. Sitemesh is nice and intercepts all pages and decorate them. However, it is very sensitive to mismatch tags. I had one <div> without close tag, and it mess all things up with the help from CSS. Furthermore, the eclipse and browser cannot validate it well, especially when I have javascript code mixed in. Maybe I should always keep the javascript in separate files.

A few small tricks.

Center block

.mycenter {
margin-left:auto;
margin-right:auto;
}

A absolute value box sit in the center

div#page {
width: 780px;


/* start to use the new absolute position system
*/
position: absolute;
left: 50%;
margin-left: -390px;
top: 5px;
}



Dojo, GWT

I have been looking into Dojo for a about 10 days. It is better than the plain javascript. And widgets are nice. Well, if I think about it again now, I might stick with GWT. Javascript is really not good for any developing.

Firebug/Chrome developing is kind of nice, but you run into lots more simple bugs that require lots of time. A simple thing such as typo in variable names and strings is usually silently ignored by browser and takes forever to debug. There I really miss java. I originally think to push more into the dojo side, but now I feel that I should keep as much in java side as possible. Much easier to handle and debug. Next time, if I need a really nice javascript site, I will definitely go to GWT. The java simulator at the beginning must be much easier.

Something nice for javascript. The pervasiveness of anonymous class, inner class, closure, are really nice features and open my eyes for new stuff. And Dojo DataGrid looks much nicer and supports much more features than the simple JSP Displaytag from Appfuse.

NEMADIY

I have been working on NEMADIY for more than half a year. This summer I work full-time for it. It is a fairly large project. There are 7-10 people working on it at one moment. I am mostly working on the front-end, the DIY module. Amit started it with Appfuse, which in turn uses whole bunch of tools: Spring MVC, struts-menu, sitemesh, prototype.... At the beginning, I am just helped Amit to modify things a bit. But over the time, I started to take the DIY as my responsibilty.

We added Spring webflow for a widzard-like process. Amit knows nothing about it. Another programmer Andrew, who has some experience with webflow, help me. Recently I start to look into Dojo, a javascript framework (prototype does not have widget system), to implement a datagrid for better looking.

In March, I spent a month to investigate GWT, we thought about to move to it completely. But I am completely new on it, and others are the same. We finally ditched the idea as we are not sure it is good for a big system as ours. We instead, used webflow to implement some parts, which also takes me about a month to learn and implement.


Well more stories about each later.

Switch the Gear

This blog was set up as my photo diary. But I neither write diary recently or shoot photos daily. And recently I do have something like to jog down, mostly about programing because that is something I did most recently. I thought to start a new blog, but why not just reuse this old blog. So here I am again, a different title and description and some new posts.