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