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 > <tre...@tremel-computer.de> 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 <tre...@tremel-computer.de> >>> 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 >>> <?xml version="1.0" encoding="UTF8"?> >>> <toolchains> >>> <toolchain> >>> <type>jdk</type> >>> <provides> >>> <version>1.6</version> >>> <vendor>oracle</vendor> >>> </provides> >>> <configuration> >>> <jdkHome>/home/martin/devel/java-6/</jdkHome> >>> </configuration> >>> </toolchain> >>> <toolchain> >>> <type>jdk</type> >>> <provides> >>> <version>1.7</version> >>> <vendor>oracle</vendor> >>> </provides> >>> <configuration> >>> <jdkHome>/home/martin/devel/java-7/</jdkHome> >>> </configuration> >>> </toolchain> >>> <toolchain> >>> <type>jdk</type> >>> <provides> >>> <version>1.8</version> >>> <vendor>oracle</vendor> >>> </provides> >>> <configuration> >>> <jdkHome>/home/martin/devel/java-8/</jdkHome> >>> </configuration> >>> </toolchain> >>> <toolchain> >>> <type>jdk</type> >>> <provides> >>> <version>1.9</version> >>> <vendor>oracle</vendor> >>> </provides> >>> <configuration> >>> <jdkHome>/home/martin/devel/java-9/</jdkHome> >>> </configuration> >>> </toolchain> >>> </toolchains>⏎ >>> >>> >>> >>>> 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
