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
-- WBR Maxim aka solomax
