Scroller + export buttons = partial data dump about scroller HOT 4 CLOSED

Hi @karlg100 ,

That would've been the same in the previous release, too. The client only has access to what the server has sent. This forum thread here might help - there's an ajax call made to the server to get all the data.

Cheers,

Colin

from scroller.

Looking at the callbacks to the server, it appears that scroller is interjecting the length and start offsets for the export. if these are removed from the POST request, then the entire dataset is exported. going to see if I can override those settings.

from scroller.

Unfortunately, this really still breaks the basic functionality of the buttons export because the base action never finishes. I ended up having to implement a workaround since scroller /w server side and buttons really aren't compatible.

The way I worked around this, add a new flag to my server side script to ignore start/length attributes set by scroller. I added a custom button called "load all" to change the ajax url for the server side to add an "export=true" flag to trigger this behavior and then trigger a dt.draw() to fetch all the rows, bypassing the scroller set limits. when clicked, will force a draw for which will load all fitlered rows. Once loaded, the user can use any of the default buttons to export data.

It's not perfect, but avoids stacking a bunch of callbacks to workaround preloading the data. it would be best if the buttons extension would overrirde the limits, trigger a draw, then perform the browser side export of the data.

One other issue I ran into was the cells() loss of performance issue with 1.10.18. I have manually repointed to 1.10.20 to workaround this problem as well.

from scroller.

when exporting to CSV, only exports the current records that have loaded from the server side.

As Colin says, that is to be expected. The file export functionality is client-side, so it can only export what has been populated. If you are using server-side processing, then that is a sub-set of the data. That is noted in this FAQ.

One other issue I ran into was the cells() loss of performance issue with 1.10.18. I have manually repointed to 1.10.20 to workaround this problem as well.

Upgrading to the latest version sounds like the correct thing to do. There were indeed some performance improvements in 1.10.20.

from scroller.