The Darwinism of Deprecation

FusionCharts has been evolving as a more powerful and contemporary JavaScript charting library. With the new features of v3.2, a large number of functions were added, and four functions got deprecated. Three of these functions were previously part of the most used functions of FusionCharts JS. In a scenario like this, the setting was perfect to tell you our story of the survival of the fittest.

The Deprecation of getChartFromId Function

getChartFromId was used to get a reference to a chart’s Flash object (HTML OBJECT/EMBED tag) after a chart had been rendered. This allowed users to do a lot of things like update chart’s data or re-render an already existing chart. But since the addition of JavaScript charting capability in FusionCharts 3.2 getChartFromId had to be deprecated.

For the JavaScript charts, getChartFromId did not make sense as there was no OBJECT/EMBED tag involved. Unlike Flash charts, where the chart’s ExternalInterface1 functions (like setDataUrl, setDataXML) were part of the HTML OBJECT/EMBED element, the JavaScript charts are fully controlled by the JavaScript object variable of every chart.

Furthermore, the getChartFromId method was available as a global2 method in JavaScript. Though this was helpful in most ways, it was still vulnerable to being overwritten by other JavaScript libraries that have its own charting library. And with more and more websites using multiple JavaScript libraries, we felt it was better to be safe than sorry.

Beyond these, for some users, there was also a confusion between the JavaScript object of a chart and the HTML OBJECT/EMBED node variablevar chartObj = new FusionCharts(...) and later write somewhere else var myChart = getChartFromId(...), the values of the two variables chartObj and myChart are not the same. chartObj is the JavaScript variable that is used to render a chart and myChart is the DOM’s HTML OBJECT/EMBED tag reference that contains functions made available by the SWF of the Flash chart. The latter is available only after the chart is rendered using the render() function of the JavaScript variable.">3. FusionCharts v3.2 bridges the gap between the two by copying the functionalities of one to the other – thus making getChartFromId redundant.

Currently Recommended Ways to Access a Chart Using Its ID

As of FusionCharts 3.2 and above, the alternative to getChartFromId is the FusionCharts.items[] collection.

Whenever a new chart is created, a reference to it is kept within the FusionCharts.items object. Consequently, if your original code was var myChart = getChartFromId("my-chart-id"), it can now be achieved using var myChart = FusionCharts.items["my-chart-id"].

Another alternate is to access the FusionCharts() function itself: var myChart = FusionCharts("my-chart-id"). Note the absence of the new keyword. While creating a new chart, we write new FusionCharts(...), but for accessing an already created chart, we drop the new keyword and simply pass the chart’s id as parameter. Ain’t it cool!?

Deprecation of setDataXML and setDataURL at JavaScript Level

Providing JSON Data Format support proved to be more of a nomenclature challenge than a technological one!

The setDataXML and setDataURL functions were conceived when JSON as a information exchange format was in its neonatal stage. Now when we were adding JSON support, what could we name the corresponding data-setting functions as? setJSONData could have been fine had the name setDataURL been a bit more accommodative. Imagine setDataURLJSON or setJSONDataURL!

Thus, we had to deprecate setDataXML and setDataURL to give way for function names that would be format-independent. By format-independent we mean that the function names should have such a pattern that in case any new format comes up, naming it should not be challenging.

Setting Data For Various FusionCharts Data Formats

The setDataXML and setDataURL functions got replaced using setXMLData>and setXMLUrl respectively. And from that, guessing the JSON functions as setJSONData and setJSONUrl is apparently not challenging at all.

We also introduced a couple of more multi-tasking data-setting functions namely: setChartData and setChartDataUrl. These functions take up two parameters: first is the source data and second is the format specification of the source. Head over to the documentation to know more.

Getting back to the point: simply replacing setDataXML with setXMLData and setDataURL with setXMLUrl is all you need to do to get going.

There Was Once an addVariable Function

Long long time ago, before the time of FusionCharts 3.2, there lived one of the lesser-known and lesser-used functions of FusionCharts JS. It allowed users to pass specific information to the flash chart files using FlashVars. FlashVars (evident from its name) was something very specific to Flash. Setting of Chart Messages and visual configuration of the Grid Component was heavily dependent on this function. With the FusionCharts JavaScript library becoming technology-independent (since the inclusion of JavaScript charting), the dependency on FlashVars was removed.

Passing FlashVars To Charts The Correct Way

In FusionCharts 3.2, the basic chart configurations sent using FlashVars can be passed during construction of a new FusionCharts. However, extended FlashVars (like “Chart Messages”) can be passed using the configure() function available since FusionCharts 3.2.0.

If your application already has .addVariable(), simply replace it with .configure().

Summary of the Deprecated Methods

To quickly summarize, here is the list of deprecated methods discussed above.

Deprecated Method Alternative Implementation
getChartFromId(chartId) FusionCharts(chartId)
setDataXML(xmlData) setXMLdata(xmlData)
setDataURL(url) setXMLUrl(url)
addVariable(key, value) configure(key, value)

This is our story of how the fittest survived in this never-ending war to become more powerful, useful and, for this case, more programmable!


  1. The ExternalInterface of an SWF object enables straightforward communication between the SWF and the Flash Player container– for example, an HTML page with JavaScript. []
  2. Local variables exist only within a particular function where it is defined. Global variables, on the other hand are present throughout the script and they can be accessed by any function. []
  3. When we write [crayon-59959cdeea119437556288-i/] and later write somewhere else [crayon-59959cdeea127563079252-i/], the values of the two variables [crayon-59959cdeea135145992932-i/] and [crayon-59959cdeea143894899756-i/] are not the same. [crayon-59959cdeea150227121418-i/] is the JavaScript variable that is used to render a chart and [crayon-59959cdeea15e760714896-i/] is the DOM’s HTML OBJECT/EMBED tag reference that contains functions made available by the SWF of the Flash chart. The latter is available only after the chart is rendered using the render() function of the JavaScript variable. []
  • Ruby August 25, 2014, 2:01 pm

    I want change data of chart, so I use “setChartData(jsonstr, “json”)”, it is ok using IE10, but the page is unchanged when I trigger the button for changing data using IE8.
    Did I miss some thing?

  • Swarnam August 26, 2014, 1:02 pm

    Hi Ruby,

    Can you please send us the scaled down sample to “”? We would be able to assist you further.

Leave a Comment