Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: EE-3.3.0.GA_P01, 4.0.BETA
-
Fix Version/s: 4.0, EE-3.3.0.GA_P03
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ICEfaces3/trunk revision# 37781, EE-3.3.0.GA Maintenance Branch, Icefaces 4 trunk.
-
Assignee Priority:P3
Description
Test application is located at: iceads1/Public/QA/JIRAs/ICE-9569.war
There are issues when swapping the backing data of the table when sorting and/or filtering are applied.
Filtering Issue:
The data set that is shown after swapping the data is always one step behind. Once filtered, swapping the data the first time doesn't appear to do anything visually but the data has actually swaped in the back end. Swapping the data again makes it appear the data has swapped correctly but it is actually still one swap behind. If you remove the filter it will show the correct data.
To reproduce:
1) Deploy test app
2) Type a character into one of the filter fields
3) Click 'Swap Data'. This first click will appear to do nothing but the data has actually swapped in the bean.
4) Click 'Swap Data' again. This time the data appears to swap but it is actually the data set that was supposed to be shown in the previous swap.
5) Remove the filter. The correct data is shown (the opposite to what is shown when filtering is applied).
Sorting:
There are no issues with the data actually swapping when sorting but the sorting does not get applied to the newly swapped data.
To reproduce:
1) Deploy test app
2) Sort one of the columns into a new order
3) Click 'Swap Data'. The sorting that was previously applied will not carry over to the new data set.
There are issues when swapping the backing data of the table when sorting and/or filtering are applied.
Filtering Issue:
The data set that is shown after swapping the data is always one step behind. Once filtered, swapping the data the first time doesn't appear to do anything visually but the data has actually swaped in the back end. Swapping the data again makes it appear the data has swapped correctly but it is actually still one swap behind. If you remove the filter it will show the correct data.
To reproduce:
1) Deploy test app
2) Type a character into one of the filter fields
3) Click 'Swap Data'. This first click will appear to do nothing but the data has actually swapped in the bean.
4) Click 'Swap Data' again. This time the data appears to swap but it is actually the data set that was supposed to be shown in the previous swap.
5) Remove the filter. The correct data is shown (the opposite to what is shown when filtering is applied).
Sorting:
There are no issues with the data actually swapping when sorting but the sorting does not get applied to the newly swapped data.
To reproduce:
1) Deploy test app
2) Sort one of the columns into a new order
3) Click 'Swap Data'. The sorting that was previously applied will not carry over to the new data set.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
There are issues when swapping the backing data of the table when sorting and/or filtering are applied.
Filtering Issue: The data set that is shown after swapping the data is always one step behind. Once filtered, swapping the data the first time doesn't appear to do anything visually but the data has actually swaped in the back end. Swapping the data again makes it appear the data has swapped correctly but it is actually still one swap behind. If you remove the filter it will show the correct data. To reproduce: 1) Deploy test app 2) Type a character into one of the filter fields 3) Click 'Swap Data'. This first click will appear to do nothing but the data has actually swapped in the bean. 4) Click 'Swap Data' again. This time the data appears to swap but it is actually the data set that was supposed to be shown in the previous swap. 5) Remove the filter. The correct data is shown (the opposite to what is shown when filtering is applied). Sorting: There are no issues with the data actually swapping when sorting but the sorting does not get applied to the newly swapped data. To reproduce: 1) Deploy test app 2) Sort one of the columns into a new order 3) Click 'Swap Data'. The sorting that was previously applied will not carry over to the new data set. |
Test application is located at: iceads1/Public/QA/JIRAs/ There are issues when swapping the backing data of the table when sorting and/or filtering are applied. Filtering Issue: The data set that is shown after swapping the data is always one step behind. Once filtered, swapping the data the first time doesn't appear to do anything visually but the data has actually swaped in the back end. Swapping the data again makes it appear the data has swapped correctly but it is actually still one swap behind. If you remove the filter it will show the correct data. To reproduce: 1) Deploy test app 2) Type a character into one of the filter fields 3) Click 'Swap Data'. This first click will appear to do nothing but the data has actually swapped in the bean. 4) Click 'Swap Data' again. This time the data appears to swap but it is actually the data set that was supposed to be shown in the previous swap. 5) Remove the filter. The correct data is shown (the opposite to what is shown when filtering is applied). Sorting: There are no issues with the data actually swapping when sorting but the sorting does not get applied to the newly swapped data. To reproduce: 1) Deploy test app 2) Sort one of the columns into a new order 3) Click 'Swap Data'. The sorting that was previously applied will not carry over to the new data set. |
| Assignee | Nils Lundquist [ nils.lundquist ] |
| Assignee | Nils Lundquist [ nils.lundquist ] | Arturo Zambrano [ artzambrano ] |
| Assignee Priority | P2 [ 10011 ] |
The issue is easily fixed by reprocessing filters and sortings at the beginning of encodeEnd() in the table renderer. This is so, because the model is swapped in the INVOKE_APPLICATION phase, which is after all the filters and sortings have been processed. A more optimal solution would avoid having to process filters and sortings twice.
Show
Arturo Zambrano
added a comment - - edited The issue is easily fixed by reprocessing filters and sortings at the beginning of encodeEnd() in the table renderer. This is so, because the model is swapped in the INVOKE_APPLICATION phase, which is after all the filters and sortings have been processed. A more optimal solution would avoid having to process filters and sortings twice.
| Fix Version/s | 4.0 [ 11382 ] | |
| Fix Version/s | 4.0.BETA [ 10770 ] |
| Environment | ICEfaces3/trunk revision# 37781 | ICEfaces3/trunk revision# 37781, EE-3.3.0.GA Maintenance Branch, Icefaces 4 trunk. |
| Affects Version/s | EE-3.3.0.GA_P01 [ 11174 ] |
Show
Arturo Zambrano
added a comment - Marking issue as resolved after applying fix described in previous comment. The same fix had to be implemented to solve two other issues, ICE-9542 and ICE-10074 , and it had to be done at the render phase. So, it's not possible to optimize further.
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
Verfied ICEfaces 4 trunk r42519, Tomcat 7, all browsers.
Show
Liana Munroe
added a comment - Verfied ICEfaces 4 trunk r42519, Tomcat 7, all browsers.
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Verified ICEfaces EE-3.3.0 maintenance branch r44437. Tomcat 7, FF 34, IE 11, Chrome 41.
Show
Liana Munroe
added a comment - Verified ICEfaces EE-3.3.0 maintenance branch r44437. Tomcat 7, FF 34, IE 11, Chrome 41.
possible backport to 3.3.0_P03.....leave this one until Ken returns extra time to backport/test.
Show
Judy Guglielmin
added a comment - possible backport to 3.3.0_P03.....leave this one until Ken returns extra time to backport/test.
| Resolution | Fixed [ 1 ] | |
| Status | Closed [ 6 ] | Reopened [ 4 ] |
| Assignee Priority | P2 [ 10011 ] | P3 [ 10012 ] |
| Security | Private [ 10001 ] |
| Fix Version/s | EE-3.3.0.GA_P03 [ 11572 ] |
| Status | Reopened [ 4 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Closed [ 6 ] | Reopened [ 4 ] |
| Security | Private [ 10001 ] |
| Status | Reopened [ 4 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Issue reproduced also with IF4 trunk rev# 39869.