Right now we have this code comment in webform_chart module above the _webform_chart_analysis_grid() function:

 * Implements _webform_analysis_component(). This is shoe-horned in below in webform_results_chart, and is necessary
 * because the core grid analysis component returns a rendered HTML table, not data, so it is useless for charting. This
 * formats the grid components as separate question/answer sets which are added to the main set of questions below.

I'm well aware that the the analysis functions provide very convenient arrays for charting, but I couldn't figure out a good way of returning the data to Webform and for a charting solution. Since there weren't any charting solutions at the time anyway, I didn't worry about it too much.

I'd *love* to patch Webform so that the grid analysis function returned some useful charting format. Actually I was worried that all the existing alaysis arrays aren't very adequate either, so if you can think of a better way of returning that information, I'd love to hear any suggestions.

Comments

hotspoons’s picture

hotspoons commented

Thanks quicksketch! After playing with the original author's module (this based on the work of this sandbox project, and I am talking to that module's author regarding a full project release), I found that the way that analysis component array structures were formatted didn't provide adequate data for chart data, especially with complex/compound components. If you look in the webform_results_chart function, I return the original components along with the parsed charting data in the main $data array.

I'd be more than happy to author a patch for the core webform module to support data structures more conducive to charting and independent analysis. There are two ways I could approach this; one would be adding new hooks to each component, like '_webform_analysis_data_grid'; the other would be extending the current analysis components with perhaps a 3rd optional argument that would direct each analysis component to return structures useful for charting. Let me know which approach you would prefer, and I'll get cracking on it over the next week. Thanks!

hotspoons’s picture

hotspoons commented
Status: Active » Needs work

Updating status.

quicksketch’s picture

quicksketch
he/him
commented

You're probably more familiar with what data is actually valuable than I am. I was just thinking about charting a little bit when I last was working on the *_analysis functions.

From a backwards-compatibility standpoint, a new function would be the safest approach. Then we could break out the existing queries in most of the *_analysis functions and move them to the new function. The name "_webform_analysis_data_[component]" sounds good to me too, if you'd like to take that approach.

hotspoons’s picture

hotspoons commented
Status: Needs work » Patch (to be ported)

Alright, I put the patch on your issue queue: http://drupal.org/node/1459372 . Currently, most of the new functions just proxy the old functions since they had most of the data needed (besides the original component) for charting; it may make sense to reverse this, especially for the _webform_analysis_grid function since all it needs to do is walk over the same data from the _webform_analysis_data_grid implementation and format a table. Well, for now it should work. Let me know what you think we should do.

ccoppen’s picture

ccoppen commented

I'm currently testing out what you added and hope to finally get around to making this a full release. It looks like we'll have to make it a full release off your sandbox as I can't change the name on my sandbox. Thanks for the work you've done.

dom.’s picture

dom. commented
Version: » 7.x-1.x-dev
Component: Code » Bug
Status: Patch (to be ported) » Closed (fixed)

Commited by Webform maintainer: see #1459372: Patch to provide usefully formatted data structures for 3rd party webform analysis (e.g. charts)

  • Commit c98e892 on master, 7.x-1.x, 7.x-2.x by hotspoons: 
    Issue #1451102 by quicksketch : Added checks to see if...