ICEfaces
  1. ICEfaces
  2. ICE-7561

MyFaces: showcase app ace:contextMenu demo "reset all" button doesn't work the first time it's pressed

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.RC1
    • Fix Version/s: 3.0.RC2, 3.0
    • Component/s: Sample Apps
    • Labels:
      None
    • Environment:
      ICEfaces 3, Showcase sample app, context menu demo, MyFaces 2.1.3
    • Assignee Priority:
      P1

      Description

      ace:contextMenu: demo in showcase sample app.:

      In a Table:
      All browsers: It takes two clicks of 'Undo All' to see the cars removed after adding cars to the table.

      This works fine with Mojarra but not with MyFaces.

        Activity

        Hide
        Deryk Sinotte added a comment -

        Looks like the actionListener is getting called properly and that the list of items is properly reset during INVOKE_APPLICATION phase. However, when I dump out the contents of the old and new DOM during the diff, the extra row items that were added are still in there. My suspicion is that there is a state-saving subtlety involved here.

        Show
        Deryk Sinotte added a comment - Looks like the actionListener is getting called properly and that the list of items is properly reset during INVOKE_APPLICATION phase. However, when I dump out the contents of the old and new DOM during the diff, the extra row items that were added are still in there. My suspicion is that there is a state-saving subtlety involved here.
        Hide
        Deryk Sinotte added a comment -

        Removing the saveState and restoreState logic from DataTable seems to do the trick. It was the "old" JSF 1.x style state saving. Instead we defer to the UIData parent class to do it the modern way.

        I ran through the datatable on both Mojarra and MyFaces and didn't seen any obvious side-effects from removing the code. On the plus side, it also seems to have fixed http://jira.icefaces.org/browse/ICE-7560.

        Show
        Deryk Sinotte added a comment - Removing the saveState and restoreState logic from DataTable seems to do the trick. It was the "old" JSF 1.x style state saving. Instead we defer to the UIData parent class to do it the modern way. I ran through the datatable on both Mojarra and MyFaces and didn't seen any obvious side-effects from removing the code. On the plus side, it also seems to have fixed http://jira.icefaces.org/browse/ICE-7560 .
        Hide
        Mark Collette added a comment -

        Had to revert, since we do need to store that info. Will reassess how this might have to be adapted to work with MyFaces.

        icefaces 3
        Subversion 26842

        Show
        Mark Collette added a comment - Had to revert, since we do need to store that info. Will reassess how this might have to be adapted to work with MyFaces. icefaces 3 Subversion 26842
        Hide
        Ken Fyten added a comment -

        saveState changes had to be reverted for now.

        Show
        Ken Fyten added a comment - saveState changes had to be reverted for now.
        Hide
        Nils Lundquist added a comment -

        State saving fixes in r26879 didn't resolve this issue, likely the original fix to caching resulted in table state reevaluating and covering up the cause of this bug, so I'm detaching it from that issue for further analysis.

        Show
        Nils Lundquist added a comment - State saving fixes in r26879 didn't resolve this issue, likely the original fix to caching resulted in table state reevaluating and covering up the cause of this bug, so I'm detaching it from that issue for further analysis.
        Hide
        Nils Lundquist added a comment - - edited

        r26883 - Fixed MyFaces table + other component out of sync interaction. MyFaces appears to generate the DataModel for the DataTable lifecycle before the feature being used in this issue has a chance to alter the backing List of the DataTable. Since the DataModel is cached for the life of the component (as was derived from the Mojarra behaviour for getDataModel) we must regenerate the dataModel prerender to catch the changes that have been made. This is required in Mojarra when the DataTable has altered its own backing List during the lifecycle, for example in filtering. The autofiltering the table attempts during its first render is responsible for the state saving change Deryk originally made fixing the issue by continually attempting a filter, and thus regenerating the model.

        Show
        Nils Lundquist added a comment - - edited r26883 - Fixed MyFaces table + other component out of sync interaction. MyFaces appears to generate the DataModel for the DataTable lifecycle before the feature being used in this issue has a chance to alter the backing List of the DataTable. Since the DataModel is cached for the life of the component (as was derived from the Mojarra behaviour for getDataModel) we must regenerate the dataModel prerender to catch the changes that have been made. This is required in Mojarra when the DataTable has altered its own backing List during the lifecycle, for example in filtering. The autofiltering the table attempts during its first render is responsible for the state saving change Deryk originally made fixing the issue by continually attempting a filter, and thus regenerating the model.

          People

          • Assignee:
            Nils Lundquist
            Reporter:
            Ken Fyten
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: