Loading data into d3.js graphs

mike thompson mithomps at redhat.com
Thu Aug 30 15:29:43 UTC 2012


Concerning auth/authz. We are in the same session so we are authenticated. All the REST services use an auth interceptor that grabs the authenticated user from the RHQ_Session cookie.  BTW this is already being done in the REST reports.

On Aug 30, 2012, at 8:18 AM, Lukas Krejci <lkrejci at redhat.com> wrote:

> 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
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list