ChartWrapper Return Values & Method Chaining

[Cyle Hunter]

I'm currently in the process of trying to refactor code and noticed a pretty common scenario when working with the chartwrapper object throughout my code, e.g.:

                chart.setChartType data.type
                chart.setDataTable tables[ti - data.tables.length]
                chart.setOptions data.options
                chart.setOption "width", div.width()
                chart.draw div.get(0)

So I thought to myself, "Hey! This this would look a lot better if I simply chained all of these methods together?" Which would look like this in coffeescript:

chart.setChartType(data.type).setDataTable(tables[ti - data.tables.length]).setOptions(data.options).setOption("width", div.width()).draw div.get(0)

Beautiful! Alas, it wouldn't run as none of these chartwrapper methods have any return values. Is there perhaps some sort of design consideration for why these methods don't have return values? Does anybody see value in adding something like this to the API?

[Sergey Grabkovsky]

Hi Cyle, the recommended usage for the ChartWrapper is constructing it with an object that has those options already set, and only setting those options when you need to change something. That being said, it's an interesting suggestion, and as a fan of jQuery, one I personally wouldn't be against.

- Sergey

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-visualization-api/-/KgWY3LHY82wJ.
To post to this group, send email to google-visua...@googlegroups.com.
To unsubscribe from this group, send email to google-visualizati...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-visualization-api?hl=en.

[Cyle Hunter]

Hi Sergey, I think for most people the recommended usage as shown in the docs is the best approach. However for my particular use case I have many charts built server-side using a single unobtrusive javascript interface that's receiving JSON to programatically define how charts need to be constructed. This seemed like a much more favorable solution than to have to write a new javascript file for each of my many charts. The drawback was that my single JS file had to get a little messy to handle various charts and options which got pretty messy and tricky to read. That said I'm looking for opportunities to make things a little more succinct and this was one of the biggest redundancies that I had noticed in my code so I thought I'd bring it up.

[Cyle Hunter]

Even beyond my use case, you see things like this in the official docs:

     var data = new google.visualization.DataTable();
    data.addColumn('string', 'N');
    data.addColumn('number', 'Value');
    data.addRow(['V', 200]);

It would be great if we could instead do:

var data = new google.visualization.DataTable();
data.addColumn('string', 'N').addColumn('number', 'Value').addRow(['V', 200]);

[Sergey Grabkovsky]

It seems like your server could return the since JSON structure that the ChartWrapper constructor takes, so that you wouldn't need this kind of code. Unless you set things piece by piece. If I were you, my service would return a JSON object that contains everything that the ChartWrapper needs, which means that the server wouldn't need to send any code to the client after the initial send. But I obviously don't know the inner workings of your systems, and what you're doing may be the right way to go.

- Sergey

On Mon, Dec 10, 2012 at 4:00 PM, Cyle Hunter <cylehu...@gmail.com> wrote:

Hi Sergey, I think for most people the recommended usage as shown in the docs is the best approach. However for my particular use case I have many charts built server-side using a single unobtrusive javascript interface that's receiving JSON to programatically define how charts need to be constructed. This seemed like a much more favorable solution than to have to write a new javascript file for each of my many charts. The drawback was that my single JS file had to get a little messy to handle various charts and options which got pretty messy and tricky to read. That said I'm looking for opportunities to make things a little more succinct and this was one of the biggest redundancies that I had noticed in my code so I thought I'd bring it up.

--

You received this message because you are subscribed to the Google Groups "Google Visualization API" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-visualization-api/-/lupg-z4krxMJ.