You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Dieter Tremel <tr...@tremel-computer.de> on 2017/08/07 07:36:45 UTC
Google Chart integration as candidate for wicketstuff
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 Computer http://www.tremel-computer.de
Dieter Tremel mailto:tremel@tremel-computer.de
Rebenring 16 Tel +49 871 9357080
84032 Altdorf Fax +49 871 9357081
Re: Google Chart integration as candidate for wicketstuff
Posted by Maxim Solodovnik <so...@gmail.com>.
Not my candidate in this case :)
On Wed, Aug 9, 2017 at 7:51 PM, Dieter Tremel <tr...@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 <tremel@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 <
> tremel@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
Re: Google Chart integration as candidate for wicketstuff
Posted by Dieter Tremel <tr...@tremel-computer.de>.
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 <tr...@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 <tremel@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.
Re: Google Chart integration as candidate for wicketstuff
Posted by Maxim Solodovnik <so...@gmail.com>.
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 <tr...@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 <tremel@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
Re: Google Chart integration as candidate for wicketstuff
Posted by Dieter Tremel <tr...@tremel-computer.de>.
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 <tr...@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.
>>
Re: Google Chart integration as candidate for wicketstuff
Posted by Maxim Solodovnik <so...@gmail.com>.
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 <tr...@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
>
> --
> Tremel Computer http://www.tremel-computer.de
> Dieter Tremel mailto:tremel@tremel-computer.de
> Rebenring 16 Tel +49 871 9357080
> 84032 Altdorf Fax +49 871 9357081
>
>
--
WBR
Maxim aka solomax
Re: Google Chart integration as candidate for wicketstuff
Posted by Dieter Tremel <tr...@tremel-computer.de>.
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
> <tr...@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 <tr...@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 users@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 <
>>>> tremel@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
Re: Google Chart integration as candidate for wicketstuff
Posted by Maxim Solodovnik <so...@gmail.com>.
I have added few comments
On Thu, Aug 17, 2017 at 4:24 PM, Dieter Tremel
<tr...@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 <tr...@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 users@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 <
>>> tremel@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
Posted by Dieter Tremel <tr...@tremel-computer.de>.
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 <tr...@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 users@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 <
>> tremel@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
Re: Google Chart integration as candidate for wicketstuff
Posted by Martin Grigorov <mg...@apache.org>.
Hi Dieter.
On Wed, Aug 16, 2017 at 12:53 PM, Dieter Tremel <tr...@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 users@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 <
> tremel@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
>
Re: Google Chart integration as candidate for wicketstuff
Posted by Dieter Tremel <tr...@tremel-computer.de>.
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 users@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 <tr...@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
Re: Google Chart integration as candidate for wicketstuff
Posted by Martin Grigorov <mg...@apache.org>.
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 <so...@gmail.com>
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 <tremel@tremel-computer.de
> >
> 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 <
> > tremel@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
Posted by Maxim Solodovnik <so...@gmail.com>.
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 <tr...@tremel-computer.de>
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 <
> tremel@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
Posted by Dieter Tremel <tr...@tremel-computer.de>.
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 <tr...@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
Re: Google Chart integration as candidate for wicketstuff
Posted by Martin Grigorov <mg...@apache.org>.
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 <tr...@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
>
> --
> Tremel Computer http://www.tremel-computer.de
> Dieter Tremel mailto:tremel@tremel-computer.de
> Rebenring 16 Tel +49 871 9357080
> 84032 Altdorf Fax +49 871 9357081
>
>