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