On Sep 26, 2012, at 8:30 AM, Charles Crouch <ccrouch@redhat.com> wrote:

So my mind is beginning to spin with the options :-) Can I just clarify the different places we display graphs today, and the technologies we use to render them..

a) Dashboard: Resource Metric Graph portlet [Gflot]
b) Dashboard: Resource Metric Graph: Live Graph [Gflot]
c) Inventory: Resource: Summary tab : Activity subtab: Resource Measurements portlet: Sparklines [Gflot] 
^^^ Not GFlot but jquery sparklines -- assuming we would want to consolidate this to our standard and not have a one off (lower priority)
d) Inventory: Resource: Summary tab : Activity subtab: Resource Measurements portlet (click metric name): single metric chart [iframe from portal war]
e) Inventory: Resource: Monitoring tab : Graphs subtab [iframe from portal war]
f) Inventory: Resource: Monitoring tab : Tables subtab (hit Chart Selected Metrics): multiple metric chart (really the same as (d) [iframe from portal war]
g) Timeline - which is really a specialized graph that I'm assuming we wouldn't change

Is this correct? Did I miss any?
That is it to my knowledge.

Mike
-So is the goal you have to move all of the above graphs to a new graphing package? I presume this would give us a win in terms of lines of code to maintain/learn and consistency of user experience, i.e. the graphs on the dashboard work like the graphs on the Monitoring tab.

-Given Gflot renders 50% of our charts already, can you remind me again of the advantages d3 has over it?
Visual appeal and flexibility. d3 has many more bells and whistles and can even do visualizations such as Resource Trees.  I'm assuming the purpose of GSoC project  was to have slick graphs (http://kraskniga.blogspot.com/2012/06/comparison-of-javascript-data.html). IMO: The GFlot graphs have an aged look.
If you just want to move off of portal.war then GFlot is the least effort way to go.

Thanks
Charles

----- Original Message -----




Soliciting input for next steps:




I spent yesterday messing with various combinations of excanvas.js
with aight.js and sizzle.js (also packaged in jQuery). This was
precipitated by the discovery that GFlot (the gwt packaging of
flot.js) renders canvas elements in IE8 via excanvas. So, knowing
that some form of canvas elements can be rendered in IE8 via a
polyfill (excanvas), I tried to add the extra functionality that was
needed in addition to excanvas (that I tested alone before) for the
d3.js charts to be rendered. This was NOT successful. I have not
seen anything in the forums saying there has been success with d3 on
IE8. And my three cross postings of this questions in the forums (
Quora, StackOverflow, d3 google groups) has gone unanswered.


The most probable solutions I see for next steps are (in order of
worst to best for IE8 users):


A) The current situation is that I have charting turned off for IE8
users in the Monitor Tab. I'm assuming that this means we would
leave the dashboard GFlot charts in for IE8 -- unless we want to
turn those off as well
B) Pursue server-side solution via Batik. This would give us a single
codebase, however, it is not proven yet (still a couple days work)
and IE8 users would get a static bitmapped rendering of the charts.
C) Use d3.js but use html bar charts (via divs) for IE8. The IE8
experience would be marginally worse but the codebase would be
fairly similiar as both chart types would use d3.js technology but
just different graph library solutions (html vs canvas/svg).
D) Leave the current GFlot charts in place and render them for IE8
giving IE8 users usable interactive charts. This would come at the
price of two sets of charting codebase. We would also need to
replace the iframe (portal.war) charts in monitor tab to GFlot as
well to be free of portal.war.




The solutions choice varies depending on where the priorities lie --
with IE8 users experience versus a cleaner codebase.
_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel