Loading data into d3.js graphs

mike thompson mithomps at redhat.com
Thu Aug 30 15:11:03 UTC 2012


d3.js is the javascript library that we have decided to use for our charting needs. As a pure javascript library we are integrating into smartGWT via JSNI.  As a standalone javacript library, d3 uses either csv or json for populating data in its charts. So now we have the issue of getting the data out of our services api and into json so d3.js can read.

Client Solution:
	smartGWT (java) ---> d3.js (javascript)

	--- or ---

Server Solution
	REST(JAX-RS) ---> d3.js


First, on the client-side we have many options there for transforming java objects to json.

Manually building json strings for each object
GWT Overlay types
GWT Autobeans
GWT JSON serialization libraries
Google Gson
Piriti
RestyGWT
GWT-jsonizer
gwtprojsonserializer	

Unfortunately, our server side json serializer (Jackson) is not compatible to run as a client GWT library (read as: something incompatible wont allow it to be compiled to javascript). So this opens the door to client GWT json serializers as a legitimate method of loading services data to d3 without a bunch of coding to get the data into json.  One of the factors that separates the client GWT json serializers is whether they can serialize an object graph and if it requires special annotations to serialize the object/field. For instance, Google Gson can just take a pojo object graph and serialize it to json no special manipulation or changing of the domain objects is required.

The advantages of the client side solutions is the ease of implementation. Any GWT service can be easily serialized to json with minimal coding. The disadvantages is that they are double handling the data -- the data gets sent from the server to GWT as  custom compressed json which in turn is processed and spit back out as standard json that d3.js can digest.

The server solution means wrapping up whatever services with a JAX-RS wrapper to expose them RESTfully. The downside being it is extra work, and the the upside being that service is now exposed via REST. Performance will also be better due to caching and not having to send the data to the client and then having the client create json from that data.  I believe this is the best solution because our customers are given the ability to create/customize charts for themselves.

Anyway, I'm proposing the server/JAX-RS RESTful solution as the way to load data into d3.js for the above reasons. Thoughts?


-- Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20120830/b83b1195/attachment.html>


More information about the rhq-devel mailing list