Loading data into d3.js graphs

Lukas Krejci lkrejci at redhat.com
Thu Aug 30 15:18:36 UTC 2012


What about auth/authz? Wouldn't we run into the same issues for which we 
needed to drop using REST in the reports?

On Thursday, August 30, 2012 08:11:03 mike thompson wrote:
> 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


More information about the rhq-devel mailing list