ICEfaces
  1. ICEfaces
  2. ICE-9569

ace:dataTable - Sorting/Filtering Issues When Swapping Data

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major 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.

        Activity

        Hide
        Judy Guglielmin added a comment -

        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.
        Hide
        Liana Munroe added a comment -

        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.
        Hide
        Liana Munroe added a comment -

        Verfied ICEfaces 4 trunk r42519, Tomcat 7, all browsers.

        Show
        Liana Munroe added a comment - Verfied ICEfaces 4 trunk r42519, Tomcat 7, all browsers.
        Hide
        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.

        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.
        Hide
        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.

        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.
        Hide
        Carmen Cristurean added a comment -

        Issue reproduced also with IF4 trunk rev# 39869.

        Show
        Carmen Cristurean added a comment - Issue reproduced also with IF4 trunk rev# 39869.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Cruz Miraback
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: