Interface design: serialize java graphics into D3 js
I am currently discussing legacy Java Swing applications with d3.0 in my workplace Interface design between the final output of JS graphics The current application is a desktop statistical exploration tool that uses Java2D to parse data and output graphics The application is being converted to a server / client application with a web front end
At present, graphical logic is tightly coupled with Java 2D code Although it is technically the implementation of wilkonson's graphical syntax, each component in the graphical tree is presented to Java components
I suggest refactoring the graphics system to output the structured specification of graphics (JSON, XML, anyway), and then passing it to consumers (front-end web, iPad, etc.) for actual parsing and rendering This separates the graphics structure from the actual rendering, theoretically allowing the same output / blueprint to be used in any client library or rendering format, whether D3 js,three. JS, SVG / Canvas / webgl, or native code
This seems intuitive to me, but my colleagues are very opposed to this idea Instead, they suggest adjusting the system to generate D3 JavaScript code on the server side, which the client will use directly This will require all graphics setup code to be implemented on a per graphics basis (in theory, some template engines are used to conditionally include JS in the resulting HTML) Our results will be directly linked to D3 itself They say the advantage is that the client doesn't have to do anything to render graphics output
Did I miss anything here? Is the latter approach preferable in the long run? Or am I using a previous design? Should I consider some benefits in generating JavaScript methods? Or, how can I build my argument to support a serialized graphics specification so that more people can join my design?
Solution
Gopherkhan,
Because of my limited knowledge, your solution seems more general You can't do your, then run the client locally, grab D3 JavaScript and output it to the server That is, both are connected in series, and the initial output of your method is used as the intermediate stage
Additional development time may be the reason for their suggestions, so you may have to be able to prove that it won't take longer and will provide additional benefits
Best wishes,
VeryTidyBoy