Am 07.08.2017 um 13:31 schrieb Maxim Solodovnik: > Maybe it would be possible to update current version? > I'm afraid having 2 different Google Chart modules would be too much :)
You are right, and I had a look at the existing module. But the Google API is so much different, that I decided to make a cut. Also my intention was to make a thin layer. Since the new API relies heavily on building nested options, the realization with HashMap and JSON makes it possible to read the google docs and build the options a java way, or even direct from JSON Strings. IMHO it makes no sense to hide a complex JS-API behind a complex Java-API, so you always have to know the original API *and* the Java API very well for your needs. If can do this with building the structure with well known classes like HashMap and JSON you know by heart, you mostly have to read only the Google docs. If you miss the strong type checking, of course you will not like this way. > BTW there are also > https://github.com/wicketstuff/core/tree/master/jqplot-parent for chart > drawing :) Good point, I didn't know this, perhaps I preferred SVG graphics over canvas drawing and kicked jqplot early. I think the combination of WebMarkupContainer and Behavior of jqplot could be the right way for my lib too and could solve my Ajax question. I will try that. Dieter > > On Mon, Aug 7, 2017 at 2:36 PM, Dieter Tremel <tre...@tremel-computer.de> > wrote: > >> Hello wicket-team, >> >> for a project visualizing metar weather data I used wicket-charts based >> on Highcharts in a former version >> (http://tremel-computer.no-ip.org:8080/metarstation/). Due to licensing >> of Highcharts I decided to move to Google charts, but found the >> implementation in wicketstuf outdated, since it depends on the image >> chart API, which is deprecated since 2012. >> >> So I wrote a Google Charts component based on the actual API. I am >> pleased with it, perhaps it could be helpful for other developers, so >> I'd like to give it to wicketstuff. >> >> It is rather lightweight, just enough Java to render the necessary >> JavaScript to the page header without knowledge of JavaScript. Knowledge >> of the Google API is needed to use it, it does not hide anything of the >> API, it should be quite feature complete. It is based at many points on >> org.apache.wicket.ajax.json and allows the user to build Java-Objects >> from compact JSON-Strings too, for example look at the essential class >> ChartOptions. Most of the classes are easy to understand with knowledge >> of the Google Charts API, since they are counterparts of the structure >> there. Only OptionHelper as container for convenience methods is a bit >> clumsy, but I have a different solution as a builder with a fluent >> interface in mind. gchart is actually used in a new branch of my weather >> app and does it's job there well. >> >> Perhaps you can have a look at it, if you like it, we can integrate it >> in wicketstuff. The ZIP in the attachment has already the structure with >> parent, lib and examples. I tried to write useful JavaDoc and some basic >> unit tests. The example is a quickstart giving two charts on one page, >> first one simple like Googles's Getting Started, the other more complex >> with a overview how to use the lib's features. >> >> Three issues (see TODO lines integrated in the source) are existing, but >> two are small, not blocking. The essential one is if the rendering of >> JavaScript in Chart#renderHead(final IHeaderResponse response) is >> sufficient for refreshing the chart by AJAX, I am not sure if. You can >> decide this in a second, I believe, and give me some hints to make the >> chart AJAX ready. >> >> I first wrote to Martin Grigorov since he helped me long ago to >> contribute a bit to wicketstuff. He told me he is on vacation and I >> should repeat the mail to the list. >>
