3

so here's the thing. I've got plenty of persisted "Snapshots" containing a java.sql.Timestamp and (for the sake of simplicity) an int as data.

I have a JSF page containing a primefaces 3.4.1 <p:lineChart> and behind that a ManagedBean that contains the model for the chart.

Let's say I then select a time range and fetch all the Snapshots in between that range. and populate the data model for the chart with all the Timestamps (x-axis) and all the integers (y-axis).

So what i do while populating is:

data = new HashMap<Object, Number>();        
List<Snapshot> allSnapshots = persistenceService.getAllSnapshots();
for(int i = 0; i < allSnapshots.size(); i++) {
    Snapshot s = allSnapshots.get(i);
    data.put(new Date(s.getTimestamp().getTime()), s.getData());
}
chartModel.getSeries().get(0).setData(data);

(Note: in the example code I just fetch all Snapshots, as I quickly just generated a hundred or so).

I set up the chart like this:

<p:lineChart id="chart" value="#{backingBean.chartModel}" xaxisAngle="-90">
   <f:convertDateTime pattern="HH:mm:ss"/>
</p:lineChart>

It works ok but when the model contains a hundred data points, the xaxis is just overcrowded with all the tickmarks.

What I then did is to use the primefaces' option to use a jqplot extender function. So I just add extender="extend" as attribute for the chart, where extend is the following js function :

function extend() {
      this.cfg.axes = {
          xaxis: {
              renderer: $.jqplot.DateAxisRenderer,
              rendererOptions: { tickRenderer: $.jqplot.CanvasAxisTickRenderer },
              tickOptions: {
                  showGridline: true,
                  formatString: '%H:%M',
                  angle: -90                        
             }         
         }
     }
}

This is the current version of it.. After hours of reading and trial and error, I still cannot get it right, as the following things are just never right:

  • The tick marks never get rendered as the Date never gets converted. At the moment this is just ignored and the formatString itself is displayed...
  • Additional tick marks are created left and right of the actual data, I dont want that.
  • When I only give autoscale: true as option for the jqplot extender, I would expect just the spacing between the marks turn ok. But what then happens is, that the spacing is cool but the original date labels turn into just bare numbers starting from 0 to the amount of data available.. !?

I am getting a little tired from dealing with this.....maybe I am doing something fundamentally wrong. Otherwise I have no idea why this is so complicated..

Thanks for any advice!

Cheers

Chris


EDIT:

Ok thanks to perissf, I checked this one : https://stackoverflow.com/a/14287971/870122

With the suggested extender I get the following output : http://www.abload.de/img/clipboard01y6sgj.png

(sorry I cannot post the image directly due to new user restrictions :-/ )

As you can see the tick marks are rendered correctly as HH:MM, thats very nice. But as you also can see another quite weird problem occurs:

The given time range of the snapshots is

  • Start time: 2013-01-28 13:01:25.415
  • End time: 2013-01-28 13:14:32.145

I collected these as UTC timestamps with System.currentTimeMillis() while the JVM is set to UTC in the glassfish config.

As you notice, the datapoints in the plot are shifted one hour, they start at 14:01, which looks like the values have been auto-converted to my current timezone which is UTC+1. But the leftmost xaxis tick is placed at around the original UTC value at 13:00.

I collect the timestamps UTC as I dont know in which actual timezone the application will be running, but I'd like to display the "translated" time value. So the auto shift to my timezone is a nice feature, but the xaxis scaling is actually not nice and weird.

Any suggestions how I get rid of that ?

Cheers

Chris


EDIT2:

Ok while debugging the rendered page with Firebug I stumbled upon the jqplot internal variables in the plot object, which seem to contain the min and max values for the xaxis. Min is set to the original min UTC value which is around 13:00, and max is set to the shifted UTC+1 value around 14:15.

Somehow the min value is not shifted accordingly to the automatic timezone adjustments.

All other values, that is dataBounds, data itself and so on, are all shifted nicely by one hour.

I opened a issue at Bitbucket jqplot issue tracker

Let's see.

Bye

Chris

Community
  • 1
  • 1
skombijohn
  • 375
  • 1
  • 5
  • 17
  • Related: http://stackoverflow.com/a/14287971/870122 – perissf Jan 29 '13 at 13:19
  • thank you ! I really searched my *** off, here and on google, but that one slipped through. I'll check the provided solution there. – skombijohn Jan 30 '13 at 08:00
  • Great. Let us know if that solution worked for you. – perissf Jan 30 '13 at 09:43
  • Ok, it worked a little....I'll edit the original post with the new issues.. – skombijohn Jan 30 '13 at 10:24
  • The default xaxis settings will add 20% on both sides. Probably you are observing this feature. However you can override it. I have never done it, but it seems to be an easy task – perissf Jan 30 '13 at 10:48
  • That option is called 'pad: 1.2' (default 20%). However, setting this to any value does not change anything. When I hover over a datapoint to trigger the tooltip for that point, I see the UTC+1 value of the original UTC value. One of the used technologies, PF, jqplot or maybe the browser is handling the time zone conversion, whereas the plot's xaxis range seems screwing that mechanism up.. – skombijohn Jan 30 '13 at 11:36
  • Getting closer: When I change my system time back on hour to UTC, the chart renders correctly.. So i guess, when I populate the data model on the server in the managed bean, the date values are still UTC. When the actual JSF page renders and the jqplot is executed in the browser, the points are shifted according to the reported browser's time zone. But the minimum xaxis value is not recalculated, but only the maximum value. – skombijohn Jan 30 '13 at 12:03
  • more conclusions, again edited the original question – skombijohn Jan 30 '13 at 15:05
  • I did some tests: the dates of data are displayed in local time zone format, the axis tick marks are also displayed in local time zone, the maximum axis tick mark is the latest data, BUT the minimum axis tick mark is always the first record date expressed in UTC ! – christophenoel Sep 08 '16 at 09:49

2 Answers2

0

i finally debugged the jqplot renderer and found some lines of code that cause this behaviour.

For anyone interested, please find the bugfix in the comment section here: Bitbucket issue tracker

Thanks for any help

skombijohn
  • 375
  • 1
  • 5
  • 17
0

I'm very interested in this fix but the issues on BitBucket are in a restricted area so I cannot access it. So I had myself to try to fix this AxisDateRenderer and fortunately I did :)

So the Primefaces (6.0) chart uses an old version of the JQPlot library. A bug in this version sets the minimum date axis bound being not the first value exactly, but a time older according to the locale time zone of the user browser. For example, if the first value is at 12:00 and your GMT is GMT+1, then the date axis bound minimum will be at 11:00 instead of 12:00 !

The minVale

The following line (in createTicks function) should bed replaced (note the code is written minified below)

ad = ad.getTime() + ad.getUtcOffset();

By the next line:

ad = Math.floor((ad.getTime() - ad.getUtcOffset())/r) * r + ad.getUtcOffset();

Non minified line to replace:

min = min.getTime()  + min.getUtcOffset();

With:

 min = Math.floor((min.getTime() - min.getUtcOffset())/tempti) * tempti + min.getUtcOffset();

Note that I have tried to update the chart.js of Primefaces to an earlier version , but the chart do not work anymore. I will wait for the next update of Primefaces hoping that a newer version is used. I also don't know which version of JQPlot is used in Primefaces 6.0

christophenoel
  • 308
  • 3
  • 8
  • _" I also don't know which version of JQPlot is used in Primefaces 6.0"_ easy to find. Check the PrimeFaces source... version: 1.0.8 build 1250. And 'waiting' is the wrong approach. Proactively reporting this (there already is an issue reported about including a jqplot extension) is the way to go. Request updates with reasons!!! – Kukeltje Sep 08 '16 at 13:58