ICEfaces
  1. ICEfaces
  2. ICE-9376

ice:dataPaginator - Displayed page is reset after changing the dataTable data model

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: EE-1.8.2.GA_P05, EE-1.8.2.GA_P06
          • Fix Version/s: EE-1.8.2.GA_P07
          • Component/s: ICE-Components
          • Labels:
            None
          • Environment:
            All
          • Assignee Priority:
            P1
          • Salesforce Case Reference:

            Description

            Due to the changes made in ICE-8610, this has caused a change in behavior from the P04 and older releases. When the data model is cleared and initialized with new data and the paginator is on a page other than the first one:
             - With the P04 release and older, the page would remain the same.
             - With P05 and up, the page is reset to the first one.

            I can understand that this would be the desired outcome for some customers but also other customers would like the old behavior to remain. This JIRA has been created so we can investigate a solution that will work for everyone.

              Activity

              Ascending order - Click to sort in descending order
              Arran Mccullough created issue -
              Hide
              Permalink
              Arran Mccullough added a comment -

              Attached test case that shows the current behavior.

              Steps:

              • Load welcomeICEfaces.iface
              • Move the paginator to page 2.
              • Click the "List Two" button, paginator is reset to page one.
              Show
              Arran Mccullough added a comment - Attached test case that shows the current behavior. Steps: Load welcomeICEfaces.iface Move the paginator to page 2. Click the "List Two" button, paginator is reset to page one.
              Arran Mccullough made changes -
              Field Original Value New Value
              Attachment Case12010Example.war [ 16085 ]
              Attachment Case12010Example.zip [ 16086 ]
              Arran Mccullough made changes -
              Salesforce Case Reference 5007000000RVf6uAAD
              Ken Fyten made changes -
              Fix Version/s EE-1.8.2.GA_P07 [ 10672 ]
              Ken Fyten made changes -
              Assignee Arturo Zambrano [ artzambrano ]
              Assignee Priority P1 [ 10010 ]
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #36619 Tue Jul 09 18:51:13 MDT 2013 art.zambrano ICE-9376 added 'checkPageConsistency' attribute
              Files Changed
              Commit graph MODIFY /icefaces/trunk/icefaces/component/src/com/icesoft/faces/component/datapaginator/DataPaginator.java
              Commit graph MODIFY /icefaces/trunk/icefaces/component/src/com/icesoft/faces/component/datapaginator/DataPaginatorRenderer.java
              Commit graph MODIFY /icefaces/trunk/icefaces/component-metadata/src/main/resources/conf/ice_cust_properties/cust-datapaginator-props.xml
              Hide
              Permalink
              Arturo Zambrano added a comment -

              Committed fix to trunk at revision 36619. Added 'checkPageConsistency' attribute.

              The new behaviour wasn't actually to reset to the first page. The code added for ICE-8610 was simply to check the page consistency of the paginator at render time. What happens is that this is sensitive to the order in which the new data model is evaluated. In this test case, the paginator component came BEFORE the table on the page, and it went through the render phase first. After the data model was changed, it wasn't available before the table went through the render phase, and the ensureFirstRowInRange() method gets the idea that the data model is empty, and so it resets to the first page. If the paginator is placed AFTER the table, the new data model is available by the time the paginator goes through the render phase, and in this case, the page stays the same after the change in the data model. In fact, the logic of ensureFirstRowInRange() is to only reset to the first page if there are no rows available and to set the paginator to the last available page if the new data model has fewer rows. The issue with ICE-8610 was also sensitive to the order in which things were evaluated. It seems like after a change in the data model, the table has to go through the render phase in order to completely set up the new data model. It might be possible to do something about this at the app level, if the original data model is not cleared first in the action listener method. Anyway, in order to support both the new and old behaviours, the attribute 'checkPageConsistency' was added. In other words, this attribute controls whether ensureFirstRowInRange() is called or not.

              Show
              Arturo Zambrano added a comment - Committed fix to trunk at revision 36619. Added 'checkPageConsistency' attribute. The new behaviour wasn't actually to reset to the first page. The code added for ICE-8610 was simply to check the page consistency of the paginator at render time. What happens is that this is sensitive to the order in which the new data model is evaluated. In this test case, the paginator component came BEFORE the table on the page, and it went through the render phase first. After the data model was changed, it wasn't available before the table went through the render phase, and the ensureFirstRowInRange() method gets the idea that the data model is empty, and so it resets to the first page. If the paginator is placed AFTER the table, the new data model is available by the time the paginator goes through the render phase, and in this case, the page stays the same after the change in the data model. In fact, the logic of ensureFirstRowInRange() is to only reset to the first page if there are no rows available and to set the paginator to the last available page if the new data model has fewer rows. The issue with ICE-8610 was also sensitive to the order in which things were evaluated. It seems like after a change in the data model, the table has to go through the render phase in order to completely set up the new data model. It might be possible to do something about this at the app level, if the original data model is not cleared first in the action listener method. Anyway, in order to support both the new and old behaviours, the attribute 'checkPageConsistency' was added. In other words, this attribute controls whether ensureFirstRowInRange() is called or not.
              Arturo Zambrano made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Hide
              Permalink
              Cruz Miraback added a comment -

              Confirmed new attribute functionality using the attached test application with ICEfaces EE 1.8.2.GA_P07 build2 jars. Tested in IE 6/7/8/9/10, Firefox 17/21, Chrome 27.

              Show
              Cruz Miraback added a comment - Confirmed new attribute functionality using the attached test application with ICEfaces EE 1.8.2.GA_P07 build2 jars. Tested in IE 6/7/8/9/10, Firefox 17/21, Chrome 27.
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]

                People

                • Assignee:
                  Arturo Zambrano
                  Reporter:
                  Arran Mccullough
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: