Hi,
we have a use case where the CSV file must be reloaded after it has changed (without a page refresh). I am able to find the pivot instance, however when I try to update the data like this:
pivotInstance.updateData({
filename: widget.filename,
});
OR like this
pivotInstance.updateData({
dataSourceType: "csv",
filename: widget.filename,
});
OR like this
pivotInstance.setReport({
dataSource: {
filename: widget.filename,
},
});
...a box appears that says "Loading data..." but nothing happens after that. I can see the new request being made correctly in the Chrome console, and the response is the exact same form as the first time (I even tried to reload the exact same file). There's no error in the console either, it just never completes. We are using Flexmonster 2.6.
What is the correct syntax for reloading a CSV file on a pivot that already has one?
OK, one solution (a bit of a gimmick) is to make a copy of the report object, then use .setReport to set it to null, then set it back to the original report. This will make the request again and everything works as expected. If you know a more elegant solution then please let me know.
Hello, Vesa,
Thank you for your question.
We are glad to hear that you have found a workaround that works fine for you.
We would like to point out that updateData
is the correct way how to reload a CSV file.updateData
is used the following way:
flexmonster.updateData({
filename: 'YOUR_FILE_NAME_OR_LINK_TO_THE_FILE'
});
We have prepared a JSFiddle example for a better illustration.
Please note that when the filename is the same for both the previous and updated file, the file is not reloaded.
To force the update of the data we suggest adding a timestamp as a parameter to the filename in the following way: data.csv?timestamp
Another thing to take into consideration is updating to the 2.7 version of Flexmonster since several issues have been fixed here.
Here is a link to our migration guide for assistance.
Please let us know if this works for you.
Best Regards,
Vera
Hi Vera,
I did try to add the timestamp, the end result was the same. The gimmick works though, so it's not a major issue. We'll update to 2.7 and have another look, thank you.