Not my candidate in this case :) On Wed, Aug 9, 2017 at 7:51 PM, Dieter Tremel <tre...@tremel-computer.de> wrote:
> Unfortunately not, as expected. The FAQ say: > > > Can I use charts offline? > > Your users' computers must have access to https://www.gstatic.com/ > charts/loader.js in order to use the interactive features of Google > Charts. This is because the visualization libraries that your page requires > are loaded dynamically before you use them. The code for loading the > appropriate library is part of the included script, and is called when you > invoke the google.charts.load() method. Our terms of service do not allow > you to download the google.charts.load or google.visualization code to use > offline. > > > > Am 09.08.2017 um 09:39 schrieb Maxim Solodovnik: > > I, personally, don't mind if you will change existing googlecharts module > > with new one and provide reasonable number of examples > > > > BTW is there an option to have "local google charts" i.e. without > > contacting external CDNs? > > > > On Tue, Aug 8, 2017 at 6:24 PM, Dieter Tremel <tre...@tremel-computer.de > > > > wrote: > > > >> 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. > > -- WBR Maxim aka solomax
