Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.0.1, EE-3.0.0.GA, 3.1.0.BETA2
-
Fix Version/s: 3.1, EE-3.0.0.GA_P01
-
Component/s: ACE-Components
-
Labels:None
-
Environment:Tomcat 7, Firefox, IE, Chrome
-
Assignee Priority:P1
Description
When LazyDataModel is used with datatable having pagination, it break the export feature.
To reproduce:
1. deploy attached .war file
2. Go to the ace:dataTable > Lazy Loading example.
3. Click on the button to export dataTable as cvs file.
Exported file will contain duplicate data after first page rows of the ace:dataTable.
31st record will be a duplicate of 1st row on page 1, 32nd record will be a duplicate of 2nd row on page 1 etc.
.cvs file outcome attached.
To reproduce:
1. deploy attached .war file
2. Go to the ace:dataTable > Lazy Loading example.
3. Click on the button to export dataTable as cvs file.
Exported file will contain duplicate data after first page rows of the ace:dataTable.
31st record will be a duplicate of 1st row on page 1, 32nd record will be a duplicate of 2nd row on page 1 etc.
.cvs file outcome attached.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Committed fix at revision 29851. Fixed issue so that only the current page is exported when using lazy loading in the table.
A few observations:
- Because the lazy data is loaded in the table component at the moment of rendering the table body, the data will be loaded again at the moment of clicking the export button. This is something that the app developer must take into account, since there could be some cases where it is not desired to load the data again. In this specific test case, the data is generated randomly, so the data exported and the data displayed on the page may be different, depending on which component was rendered first. This particular situation can be solved by simply preventing the data table from rendering when the export button is clicked. This can be accomplished by the use of the ace:ajax tag. It would also be convenient to have the export button in a separate form.
- This particular test case sets the row count to 60 when loading the data lazily, but the page size of the table is 31, so you might see a few rows less when exporting the second page, since the exporter won't try to export anything beyond the maximum number of rows, as one would expect. If the page size of the table is set to 30 (i.e. matching the row count specified when loading the data lazily), then you'll see the same number of rows when exporting the second page.
Show
Arturo Zambrano
added a comment - - edited Committed fix at revision 29851. Fixed issue so that only the current page is exported when using lazy loading in the table.
A few observations:
Because the lazy data is loaded in the table component at the moment of rendering the table body, the data will be loaded again at the moment of clicking the export button. This is something that the app developer must take into account, since there could be some cases where it is not desired to load the data again. In this specific test case, the data is generated randomly, so the data exported and the data displayed on the page may be different, depending on which component was rendered first. This particular situation can be solved by simply preventing the data table from rendering when the export button is clicked. This can be accomplished by the use of the ace:ajax tag. It would also be convenient to have the export button in a separate form.
This particular test case sets the row count to 60 when loading the data lazily, but the page size of the table is 31, so you might see a few rows less when exporting the second page, since the exporter won't try to export anything beyond the maximum number of rows, as one would expect. If the page size of the table is set to 30 (i.e. matching the row count specified when loading the data lazily), then you'll see the same number of rows when exporting the second page.
It seems that when using dataExporter with lazy data model it should only export those rows that have been loaded at the time of export.
Committed fix to maintenance branch at revision 30039.