Charts in GXT are rendered in SVG (I purposely ignore the VML rendering for now). I suppose the rendering code is done on client side.
Would it be possible to get a rendering on the server side too?
Beside a hack like getting the source of the chart module and modifying it to get the resulting SVG code in memory, of course.
The idea is to allow scheduled, off-line rendering of such charts, to save the result to a file or to send it by e-mail, either in pure SVG or in PNG via Batik, for example. Another usage would be to allow the user to save these files, via a link to a file on the server.
Currently, browsers offer no easy way to save a SVG to disk (unlike plain images), even less SVG generated on the fly.
It would be nice if GXT would offer such facility (server-side rendering) without requiring the user to hack the source.
I understand your point of view (that can be translated to "that's not our problem", which is OK), but we cannot use another library for off-line rendering: we want the same rendering on the client and off-line. It would be odd to show a Sencha chart in the browser and to get a JFreeChart image by mail...
Well, we will see what we can hack.
Sorry, I don't mean to suggest that it isn't our problem - perhaps I could have phrased that as 'how does this help'? Pre-generating a chart on the server means it is an image, and so can not be interacted with - even if it is SVG, that just means that it is a vector image, not that it can be interacted with.
If you are trying to just have canned data that can be drawn, viewed with the GXT charts, then the client charts will work just fine - just save a copy of data every day, and return that whenever a client asks - the ListStore bound to the data doesn't care how old the data is.
If you do want a static image (raster or vector) for both email and browser, then something like JFreeChart or the like will be the best option.
Effecient/effective server rendering has different concerns than on the browser. At least for the beta, we're focusing on the browser for a number of reasons - we have to support several different browsers (efficiently!), and allowing the user to interact with the data is one of the big things that makes client libraries useful. After 3.0, we may consider some options for doing some work on the server.
But yes, doing this work (drawing a static, non-interactive image) on the server so it can be drawn consistently for browser and email alike it probably best done with a library that specializes it in, at least for now.
I am sorry if I made your answer to sound harsher than you intended. As I wrote, it is OK to discard change suggestions if that's outside of your focus: somehow, I prefer you work on getting GXT 3 out of beta rather than acknowledging all odd requests you receive...
I know the chart code resides in 'client', so it might be hard to run it on the server. That's one issue with GWT, and you probably don't want to move it to 'shared', as probably few people would use such facility.
But I see that the meat of the code, eg. BarSeries, computing the geometry of the graphics, is pure Java. Same for the Sprite class. Apparently, only draw/engine/(SVG|VML).java files are client-specific (native), so it could be easy to make a server-side renderer to output the generated SVG to a file, for example.
Actually, I might even re-implement the draw package to use Java2D to make directly a PNG image, for example.
For this use case, we don't care for interaction, we just want a pretty, static image, identical to the one shown on the browser...
For people paying the license (I think we will take some, soon), do you allow taking some parts of the code and transforming it (eg. duplicating the above mentioned code to use it on the server) in proprietary/private code?
The main trick about building your own Surface impl on the server will be that it is created using GWT.create, which isn't possible to run on a standard JVM. But otherwise that seems like a possible direction to take. Remember too that Chart is an instance of Widget, and so assumes it will be drawn to the DOM, and there will be a lot of extra code that deals with mouse events that you won't need to be concerned with.