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