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.
