Re: Google Chart integration as candidate for wicketstuff
Hi Dieter, I've made some comments and approved the PR. Mostly minor things. I've also invited you to the WicketStuff collaborators team so you can commit in the repo, and merge PRs. You can still use PRs for your contributions when you want someone else to take a look before applying the changes. Thank you for your contributions! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Aug 23, 2017 at 7:43 PM, Maxim Solodovnik wrote: > Hello Dieter, > > I had no time to check this "in action" :( > Will try to during weekend > > On Wed, Aug 23, 2017 at 11:36 PM, Dieter Tremel > > wrote: > > > Hi, > > > > sorry for my lack of experience with pull requests. > > > > Did you have time to look at the sources? > > > > Is there anything expected from me now? What are the next steps? > > What issues to solve do you see? > > > > Dieter > > > > Am 13.08.2017 um 12:56 schrieb Martin Grigorov: > > > Hi Dieter, > > > > > > Are Google Charts versioned ? > > > Maybe we can add your library as wicketstuff-google-charts2, or > whatever > > is > > > the correct version. As we did with Google Maps APIs. > > > > > > Please create a Pull Request! > > > Thank you! > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Mon, Aug 7, 2017 at 10:36 AM, 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. > > >> > > >> Dieter Tremel > > > > > > -- > WBR > Maxim aka solomax >
Re: Google Chart integration as candidate for wicketstuff
Hello Dieter, I had no time to check this "in action" :( Will try to during weekend On Wed, Aug 23, 2017 at 11:36 PM, Dieter Tremel wrote: > Hi, > > sorry for my lack of experience with pull requests. > > Did you have time to look at the sources? > > Is there anything expected from me now? What are the next steps? > What issues to solve do you see? > > Dieter > > Am 13.08.2017 um 12:56 schrieb Martin Grigorov: > > Hi Dieter, > > > > Are Google Charts versioned ? > > Maybe we can add your library as wicketstuff-google-charts2, or whatever > is > > the correct version. As we did with Google Maps APIs. > > > > Please create a Pull Request! > > Thank you! > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Mon, Aug 7, 2017 at 10:36 AM, 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. > >> > >> Dieter Tremel > -- WBR Maxim aka solomax
Re: Google Chart integration as candidate for wicketstuff
Hi, sorry for my lack of experience with pull requests. Did you have time to look at the sources? Is there anything expected from me now? What are the next steps? What issues to solve do you see? Dieter Am 13.08.2017 um 12:56 schrieb Martin Grigorov: > Hi Dieter, > > Are Google Charts versioned ? > Maybe we can add your library as wicketstuff-google-charts2, or whatever is > the correct version. As we did with Google Maps APIs. > > Please create a Pull Request! > Thank you! > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Mon, Aug 7, 2017 at 10:36 AM, Dieter Tremel > 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. >> >> Dieter Tremel
Re: Google Chart integration as candidate for wicketstuff
Hi Maxim, thank you for looking at my source, I changed this. Uploaded new commits added to the pull request. Dieter Am 17.08.2017 um 15:14 schrieb Maxim Solodovnik: > I have added few comments > > On Thu, Aug 17, 2017 at 4:24 PM, Dieter Tremel > wrote: >> Hello Martin, >> >> made pull request #608 to wicket 7 branch. Hope it's all done as required. >> >> Did not rename till now, hope it is still possible. Just wanted to give >> you a view. >> >> AJAX is not working yet, have a look at example, bar chart, AjaxCheckBox >> for stacked percent. >> >> Cheers >> Dieter >> >> Am 16.08.2017 um 14:06 schrieb Martin Grigorov: >>> Hi Dieter. >>> >>> On Wed, Aug 16, 2017 at 12:53 PM, Dieter Tremel >>> wrote: >>> Hi Martin, Google Chart is versioned (https://developers.google.com/chart/interactive/docs/ release_notes#Releases) but only in newer "frozen versions", 41 .. 45. 45 is current. Not ideal for naming, since Google does not emphasize versioning at all. Perhaps we can create a name from "image vs. loader" based or "image vs SVG/VML" based. googlecharts-parent is based on the deprecated image api: https://developers.google.com/chart/image/ The current API is based on function from a loaded library: https://developers.google.com/chart/interactive/docs/basic_load_libs. Please make a suggestion. My library (currently named gchart-parent) has been improved since my first post: - better package structure - implemented OptionBuilder with fluent interface - make ChartOptions and JsonStringer model-aware, so values in options can be IModel - offer ChartLibLoaderBehavior for Page to avoid double library loading on pages with multiple charts by use of HeaderItem#getDependencies - more examples, new examples analog to Google's examples - tried to make chart redrawable by AJAX, but this is not finished, I have problems calling the draw callbacks when adding to target. Here I need some help. Should I write a post to us...@wicket.apache.org? I will prepare a pull request, but before I have to check: - find name (see above) >>> >>> I think the best would be to rename the old to >>> wicketstuff-google-image-charts and use wicketstuff-google-charts for the >>> new one. >>> Second option is to use wicketstuff-google-charts-loader for the new one. >>> >>> - learn maven toolchain definition >>> >>> All you need is $HOME/.m2/toolchains.xml with content like [1]. Just fix >>> the paths to match you local environment. You can remove entries for old >>> JDKs. >>> >>> - learn again how to make a neat pull request >>> >>> Fork the repo, make changes, create PR >>> >>> - fix AJAX issue - should I include my local git history in request or start with a clean history? >>> >>> This won't be easy! >>> But if you are able to merge your code in the forked WicketStuff repo and >>> preserve the history then do it. >>> It is not something really important though! >>> >>> - I mixed some lambda expressions and stream use with some traditional for loops. How should this be unified? Java 8 or not? >>> >>> Java 8 code could be used only in WicketStuff master branch, i.e. Wicket >>> 8.x. >>> If this is OK for you then everything is OK. >>> If you want to contribute it to wicket-7.x branch then it should be >>> compileable with Java 7. >>> >>> Thank you for your help Dieter >>> 1. >>> cat ~/.m2/toolchains.xml >>> >>> >>> >>> jdk >>> >>> 1.6 >>> oracle >>> >>> >>> /home/martin/devel/java-6/ >>> >>> >>> >>> jdk >>> >>> 1.7 >>> oracle >>> >>> >>> /home/martin/devel/java-7/ >>> >>> >>> >>> jdk >>> >>> 1.8 >>> oracle >>> >>> >>> /home/martin/devel/java-8/ >>> >>> >>> >>> jdk >>> >>> 1.9 >>> oracle >>> >>> >>> /home/martin/devel/java-9/ >>> >>> >>> ⏎ >>> >>> >>> Am 13.08.2017 um 12:56 schrieb Martin Grigorov: > Hi Dieter, > > Are Google Charts versioned ? > Maybe we can add your library as wicketstuff-google-charts2, or whatever is > the correct version. As we did with Google Maps APIs. > > Please create a Pull Request! > Thank you! > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Mon, Aug 7, 2017 at 10:36 AM, 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 outda
Re: Google Chart integration as candidate for wicketstuff
I have added few comments On Thu, Aug 17, 2017 at 4:24 PM, Dieter Tremel wrote: > Hello Martin, > > made pull request #608 to wicket 7 branch. Hope it's all done as required. > > Did not rename till now, hope it is still possible. Just wanted to give > you a view. > > AJAX is not working yet, have a look at example, bar chart, AjaxCheckBox > for stacked percent. > > Cheers > Dieter > > Am 16.08.2017 um 14:06 schrieb Martin Grigorov: >> Hi Dieter. >> >> On Wed, Aug 16, 2017 at 12:53 PM, Dieter Tremel >> wrote: >> >>> Hi Martin, >>> >>> Google Chart is versioned >>> (https://developers.google.com/chart/interactive/docs/ >>> release_notes#Releases) >>> but only in newer "frozen versions", 41 .. 45. 45 is current. Not ideal >>> for naming, since Google does not emphasize versioning at all. >>> >>> Perhaps we can create a name from "image vs. loader" based or "image vs >>> SVG/VML" based. googlecharts-parent is based on the deprecated image >>> api: https://developers.google.com/chart/image/ The current API is based >>> on function from a loaded library: >>> https://developers.google.com/chart/interactive/docs/basic_load_libs. >>> Please make a suggestion. >>> >>> My library (currently named gchart-parent) has been improved since my >>> first post: >>> - better package structure >>> - implemented OptionBuilder with fluent interface >>> - make ChartOptions and JsonStringer model-aware, so values in options >>> can be IModel >>> - offer ChartLibLoaderBehavior for Page to avoid double library loading >>> on pages with multiple charts by use of HeaderItem#getDependencies >>> - more examples, new examples analog to Google's examples >>> - tried to make chart redrawable by AJAX, but this is not finished, I >>> have problems calling the draw callbacks when adding to target. Here I >>> need some help. Should I write a post to us...@wicket.apache.org? >>> >>> I will prepare a pull request, but before I have to check: >>> - find name (see above) >>> >> >> I think the best would be to rename the old to >> wicketstuff-google-image-charts and use wicketstuff-google-charts for the >> new one. >> Second option is to use wicketstuff-google-charts-loader for the new one. >> >> >>> - learn maven toolchain definition >>> >> >> All you need is $HOME/.m2/toolchains.xml with content like [1]. Just fix >> the paths to match you local environment. You can remove entries for old >> JDKs. >> >> >>> - learn again how to make a neat pull request >>> >> >> Fork the repo, make changes, create PR >> >> >>> - fix AJAX issue >>> - should I include my local git history in request or start with a >>> clean history? >>> >> >> This won't be easy! >> But if you are able to merge your code in the forked WicketStuff repo and >> preserve the history then do it. >> It is not something really important though! >> >> >>> - I mixed some lambda expressions and stream use with some traditional >>> for loops. How should this be unified? Java 8 or not? >>> >> >> Java 8 code could be used only in WicketStuff master branch, i.e. Wicket >> 8.x. >> If this is OK for you then everything is OK. >> If you want to contribute it to wicket-7.x branch then it should be >> compileable with Java 7. >> >> >>> >>> Thank you for your help >>> Dieter >>> >>> >> 1. >> cat ~/.m2/toolchains.xml >> >> >> >> jdk >> >> 1.6 >> oracle >> >> >> /home/martin/devel/java-6/ >> >> >> >> jdk >> >> 1.7 >> oracle >> >> >> /home/martin/devel/java-7/ >> >> >> >> jdk >> >> 1.8 >> oracle >> >> >> /home/martin/devel/java-8/ >> >> >> >> jdk >> >> 1.9 >> oracle >> >> >> /home/martin/devel/java-9/ >> >> >> ⏎ >> >> >> >>> Am 13.08.2017 um 12:56 schrieb Martin Grigorov: Hi Dieter, Are Google Charts versioned ? Maybe we can add your library as wicketstuff-google-charts2, or whatever >>> is the correct version. As we did with Google Maps APIs. Please create a Pull Request! Thank you! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Aug 7, 2017 at 10:36 AM, 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
Re: Google Chart integration as candidate for wicketstuff
Hello Martin, made pull request #608 to wicket 7 branch. Hope it's all done as required. Did not rename till now, hope it is still possible. Just wanted to give you a view. AJAX is not working yet, have a look at example, bar chart, AjaxCheckBox for stacked percent. Cheers Dieter Am 16.08.2017 um 14:06 schrieb Martin Grigorov: > Hi Dieter. > > On Wed, Aug 16, 2017 at 12:53 PM, Dieter Tremel > wrote: > >> Hi Martin, >> >> Google Chart is versioned >> (https://developers.google.com/chart/interactive/docs/ >> release_notes#Releases) >> but only in newer "frozen versions", 41 .. 45. 45 is current. Not ideal >> for naming, since Google does not emphasize versioning at all. >> >> Perhaps we can create a name from "image vs. loader" based or "image vs >> SVG/VML" based. googlecharts-parent is based on the deprecated image >> api: https://developers.google.com/chart/image/ The current API is based >> on function from a loaded library: >> https://developers.google.com/chart/interactive/docs/basic_load_libs. >> Please make a suggestion. >> >> My library (currently named gchart-parent) has been improved since my >> first post: >> - better package structure >> - implemented OptionBuilder with fluent interface >> - make ChartOptions and JsonStringer model-aware, so values in options >> can be IModel >> - offer ChartLibLoaderBehavior for Page to avoid double library loading >> on pages with multiple charts by use of HeaderItem#getDependencies >> - more examples, new examples analog to Google's examples >> - tried to make chart redrawable by AJAX, but this is not finished, I >> have problems calling the draw callbacks when adding to target. Here I >> need some help. Should I write a post to us...@wicket.apache.org? >> >> I will prepare a pull request, but before I have to check: >> - find name (see above) >> > > I think the best would be to rename the old to > wicketstuff-google-image-charts and use wicketstuff-google-charts for the > new one. > Second option is to use wicketstuff-google-charts-loader for the new one. > > >> - learn maven toolchain definition >> > > All you need is $HOME/.m2/toolchains.xml with content like [1]. Just fix > the paths to match you local environment. You can remove entries for old > JDKs. > > >> - learn again how to make a neat pull request >> > > Fork the repo, make changes, create PR > > >> - fix AJAX issue >> - should I include my local git history in request or start with a >> clean history? >> > > This won't be easy! > But if you are able to merge your code in the forked WicketStuff repo and > preserve the history then do it. > It is not something really important though! > > >> - I mixed some lambda expressions and stream use with some traditional >> for loops. How should this be unified? Java 8 or not? >> > > Java 8 code could be used only in WicketStuff master branch, i.e. Wicket > 8.x. > If this is OK for you then everything is OK. > If you want to contribute it to wicket-7.x branch then it should be > compileable with Java 7. > > >> >> Thank you for your help >> Dieter >> >> > 1. > cat ~/.m2/toolchains.xml > > > > jdk > > 1.6 > oracle > > > /home/martin/devel/java-6/ > > > > jdk > > 1.7 > oracle > > > /home/martin/devel/java-7/ > > > > jdk > > 1.8 > oracle > > > /home/martin/devel/java-8/ > > > > jdk > > 1.9 > oracle > > > /home/martin/devel/java-9/ > > > ⏎ > > > >> Am 13.08.2017 um 12:56 schrieb Martin Grigorov: >>> Hi Dieter, >>> >>> Are Google Charts versioned ? >>> Maybe we can add your library as wicketstuff-google-charts2, or whatever >> is >>> the correct version. As we did with Google Maps APIs. >>> >>> Please create a Pull Request! >>> Thank you! >>> >>> Martin Grigorov >>> Wicket Training and Consulting >>> https://twitter.com/mtgrigorov >>> >>> On Mon, Aug 7, 2017 at 10:36 AM, 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 or
Re: Google Chart integration as candidate for wicketstuff
Hi Dieter. On Wed, Aug 16, 2017 at 12:53 PM, Dieter Tremel wrote: > Hi Martin, > > Google Chart is versioned > (https://developers.google.com/chart/interactive/docs/ > release_notes#Releases) > but only in newer "frozen versions", 41 .. 45. 45 is current. Not ideal > for naming, since Google does not emphasize versioning at all. > > Perhaps we can create a name from "image vs. loader" based or "image vs > SVG/VML" based. googlecharts-parent is based on the deprecated image > api: https://developers.google.com/chart/image/ The current API is based > on function from a loaded library: > https://developers.google.com/chart/interactive/docs/basic_load_libs. > Please make a suggestion. > > My library (currently named gchart-parent) has been improved since my > first post: > - better package structure > - implemented OptionBuilder with fluent interface > - make ChartOptions and JsonStringer model-aware, so values in options > can be IModel > - offer ChartLibLoaderBehavior for Page to avoid double library loading > on pages with multiple charts by use of HeaderItem#getDependencies > - more examples, new examples analog to Google's examples > - tried to make chart redrawable by AJAX, but this is not finished, I > have problems calling the draw callbacks when adding to target. Here I > need some help. Should I write a post to us...@wicket.apache.org? > > I will prepare a pull request, but before I have to check: > - find name (see above) > I think the best would be to rename the old to wicketstuff-google-image-charts and use wicketstuff-google-charts for the new one. Second option is to use wicketstuff-google-charts-loader for the new one. > - learn maven toolchain definition > All you need is $HOME/.m2/toolchains.xml with content like [1]. Just fix the paths to match you local environment. You can remove entries for old JDKs. > - learn again how to make a neat pull request > Fork the repo, make changes, create PR > - fix AJAX issue > - should I include my local git history in request or start with a > clean history? > This won't be easy! But if you are able to merge your code in the forked WicketStuff repo and preserve the history then do it. It is not something really important though! > - I mixed some lambda expressions and stream use with some traditional > for loops. How should this be unified? Java 8 or not? > Java 8 code could be used only in WicketStuff master branch, i.e. Wicket 8.x. If this is OK for you then everything is OK. If you want to contribute it to wicket-7.x branch then it should be compileable with Java 7. > > Thank you for your help > Dieter > > 1. cat ~/.m2/toolchains.xml jdk 1.6 oracle /home/martin/devel/java-6/ jdk 1.7 oracle /home/martin/devel/java-7/ jdk 1.8 oracle /home/martin/devel/java-8/ jdk 1.9 oracle /home/martin/devel/java-9/ ⏎ > Am 13.08.2017 um 12:56 schrieb Martin Grigorov: > > Hi Dieter, > > > > Are Google Charts versioned ? > > Maybe we can add your library as wicketstuff-google-charts2, or whatever > is > > the correct version. As we did with Google Maps APIs. > > > > Please create a Pull Request! > > Thank you! > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Mon, Aug 7, 2017 at 10:36 AM, 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 ther
Re: Google Chart integration as candidate for wicketstuff
Hi Martin, Google Chart is versioned (https://developers.google.com/chart/interactive/docs/release_notes#Releases) but only in newer "frozen versions", 41 .. 45. 45 is current. Not ideal for naming, since Google does not emphasize versioning at all. Perhaps we can create a name from "image vs. loader" based or "image vs SVG/VML" based. googlecharts-parent is based on the deprecated image api: https://developers.google.com/chart/image/ The current API is based on function from a loaded library: https://developers.google.com/chart/interactive/docs/basic_load_libs. Please make a suggestion. My library (currently named gchart-parent) has been improved since my first post: - better package structure - implemented OptionBuilder with fluent interface - make ChartOptions and JsonStringer model-aware, so values in options can be IModel - offer ChartLibLoaderBehavior for Page to avoid double library loading on pages with multiple charts by use of HeaderItem#getDependencies - more examples, new examples analog to Google's examples - tried to make chart redrawable by AJAX, but this is not finished, I have problems calling the draw callbacks when adding to target. Here I need some help. Should I write a post to us...@wicket.apache.org? I will prepare a pull request, but before I have to check: - find name (see above) - learn maven toolchain definition - learn again how to make a neat pull request - fix AJAX issue - should I include my local git history in request or start with a clean history? - I mixed some lambda expressions and stream use with some traditional for loops. How should this be unified? Java 8 or not? Thank you for your help Dieter Am 13.08.2017 um 12:56 schrieb Martin Grigorov: > Hi Dieter, > > Are Google Charts versioned ? > Maybe we can add your library as wicketstuff-google-charts2, or whatever is > the correct version. As we did with Google Maps APIs. > > Please create a Pull Request! > Thank you! > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Mon, Aug 7, 2017 at 10:36 AM, Dieter Tremel > 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. >> >> Dieter Tremel
Re: Google Chart integration as candidate for wicketstuff
Hi Dieter, Are Google Charts versioned ? Maybe we can add your library as wicketstuff-google-charts2, or whatever is the correct version. As we did with Google Maps APIs. Please create a Pull Request! Thank you! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Aug 7, 2017 at 10:36 AM, Dieter Tremel 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. > > Dieter Tremel > > -- > Tremel Computerhttp://www.tremel-computer.de > Dieter Tremel mailto:tre...@tremel-computer.de > Rebenring 16 Tel +49 871 9357080 > 84032 Altdorf Fax +49 871 9357081 > >
Re: Google Chart integration as candidate for wicketstuff
Not my candidate in this case :) On Wed, Aug 9, 2017 at 7:51 PM, Dieter Tremel 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 > > > 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 >
Re: Google Chart integration as candidate for wicketstuff
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 > 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 >> >>> 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.
Re: Google Chart integration as candidate for wicketstuff
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 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 > > > 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
Re: Google Chart integration as candidate for wicketstuff
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 > 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. >>
Re: Google Chart integration as candidate for wicketstuff
Maybe it would be possible to update current version? I'm afraid having 2 different Google Chart modules would be too much :) BTW there are also https://github.com/wicketstuff/core/tree/master/jqplot-parent for chart drawing :) On Mon, Aug 7, 2017 at 2:36 PM, Dieter Tremel 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. > > Dieter Tremel > > -- > Tremel Computerhttp://www.tremel-computer.de > Dieter Tremel mailto:tre...@tremel-computer.de > Rebenring 16 Tel +49 871 9357080 > 84032 Altdorf Fax +49 871 9357081 > > -- WBR Maxim aka solomax