Fixes #193 , Here is a summary of the changed

1. Performance improvement during load: in the previous version, the html-table is parsed on page load and the parsed data is stored in a variable ready to export.

   • Problem: The problem with this approach is that it slows down the script on page load. No, every user ends up exporting the data so parsing the data on page load is a waste of resources and caused the browser to complain about the script.

   • Solution: To fix this issue, I changed the events' orders by moving the paring code away from the initialization process. So the plugin gets initialized during page load ready to be executed and later the export code gets fired when the user clicked the export buttons.

2. Performance improvement during export: in the previous version, the html-table is parsed multiple times (depends on how many formats are available) and then that data gets stored in the session.

   • Problem: The problem with this approach, we are parsing and storing a separate set of data for each format even when not used. For example, if the user configures the script to enable “csv”, “xls”, and “txt” formats, the script will parse the html table three times and create three different datasets in the session one for each format.
   • Solution: When a user clicks on the “Export to CSV” button, we then parse the html table for “CSV” format only, store the parsed data in the session, and then export it to csv file. The same goes for each format, so if the user exports “CSV” and “XLS” we repeat the same process 2 times.
   • To Do: Instead of parsing the html table for every format, perhaps we can check to see if there are parsed data in the session and just use that data instead of parsing the html table all over again to improve the performance for additional format exports.