ICEfaces
  1. ICEfaces
  2. ICE-7959

ace:dataTable - input components in expanded rows don't save on MyFaces - iterative state saving issues

    Details

      Description

      There are several issues concerning the iterative state saving of child components in MyFaces, ultimately resulting in the failure of those components to pass validation, because their submitted values, saved in the decode phase, are missing.

      1 - MyFaces UIData caches the row index and only saves / restores row state when the row index is changed. This results in the incorrect row state for the first expanded row of the first row of the table.
      The row index is 0 for both rows, resulting in shared ids. This is a important issue as preemptively moving the UIData to row 1 (to cause state saving, while leaving the data model at row 0) prevents state saving when the expanded set iterates to index 1. Changing to -1 to force state saving causes issues in Mojarra by dumping the data model when the row index is set to -1.

      2 - Setting the row index to 0 following moving to a list of expanded row objects causes state saving in MyFaces.

      I cannot conceive of a manner of changing the root index & row index where changing the row index following the root change (which is necessary to setup request scoped variables) doesn't cause incorrectly saved state. The row index must have been changed to a row that has not been visited yet (in the case of the 0th row), to cause state saving for the parent, and the change to the 0th row of the expanded set causes state saving for that hack row change.

        Activity

        Nils Lundquist created issue -
        Nils Lundquist made changes -
        Field Original Value New Value
        Assignee Nils Lundquist [ nils.lundquist ]
        Nils Lundquist made changes -
        Link This issue duplicates ICE-7936 [ ICE-7936 ]
        Nils Lundquist made changes -
        Salesforce Case []
        Description There are several issues concerning the iterative state saving of child components in MyFaces, ultimately resulting in the failure of those components to pass validation, because their submitted values, saved in the decode phase, are missing. There are several issues concerning the iterative state saving of child components in MyFaces, ultimately resulting in the failure of those components to pass validation, because their submitted values, saved in the decode phase, are missing.

        1 - MyFaces UIData caches the row index and only saves / restores row state when the row index is changed. This results in the incorrect row state for the first expanded row of the first row of the table.
        The row index is 0 for both rows, resulting in shared ids.

        2 - Setting the row index to 0 following moving to a list of expanded row objects causes state saving in MyFaces.
        Nils Lundquist made changes -
        Salesforce Case []
        Description There are several issues concerning the iterative state saving of child components in MyFaces, ultimately resulting in the failure of those components to pass validation, because their submitted values, saved in the decode phase, are missing.

        1 - MyFaces UIData caches the row index and only saves / restores row state when the row index is changed. This results in the incorrect row state for the first expanded row of the first row of the table.
        The row index is 0 for both rows, resulting in shared ids.

        2 - Setting the row index to 0 following moving to a list of expanded row objects causes state saving in MyFaces.
        There are several issues concerning the iterative state saving of child components in MyFaces, ultimately resulting in the failure of those components to pass validation, because their submitted values, saved in the decode phase, are missing.

        1 - MyFaces UIData caches the row index and only saves / restores row state when the row index is changed. This results in the incorrect row state for the first expanded row of the first row of the table.
        The row index is 0 for both rows, resulting in shared ids. This is a important issue as preemptively moving the UIData to row 1 (to cause state saving, while leaving the data model at row 0) prevents state saving when the expanded set iterates to index 1. Changing to -1 to force state saving causes issues in Mojarra by dumping the data model when the row index is set to -1.

        2 - Setting the row index to 0 following moving to a list of expanded row objects causes state saving in MyFaces.
        Nils Lundquist made changes -
        Salesforce Case []
        Description There are several issues concerning the iterative state saving of child components in MyFaces, ultimately resulting in the failure of those components to pass validation, because their submitted values, saved in the decode phase, are missing.

        1 - MyFaces UIData caches the row index and only saves / restores row state when the row index is changed. This results in the incorrect row state for the first expanded row of the first row of the table.
        The row index is 0 for both rows, resulting in shared ids. This is a important issue as preemptively moving the UIData to row 1 (to cause state saving, while leaving the data model at row 0) prevents state saving when the expanded set iterates to index 1. Changing to -1 to force state saving causes issues in Mojarra by dumping the data model when the row index is set to -1.

        2 - Setting the row index to 0 following moving to a list of expanded row objects causes state saving in MyFaces.
        There are several issues concerning the iterative state saving of child components in MyFaces, ultimately resulting in the failure of those components to pass validation, because their submitted values, saved in the decode phase, are missing.

        1 - MyFaces UIData caches the row index and only saves / restores row state when the row index is changed. This results in the incorrect row state for the first expanded row of the first row of the table.
        The row index is 0 for both rows, resulting in shared ids. This is a important issue as preemptively moving the UIData to row 1 (to cause state saving, while leaving the data model at row 0) prevents state saving when the expanded set iterates to index 1. Changing to -1 to force state saving causes issues in Mojarra by dumping the data model when the row index is set to -1.

        2 - Setting the row index to 0 following moving to a list of expanded row objects causes state saving in MyFaces.

        I cannot conceive of a manner of changing the root index & row index where changing the row index following the root change (which is necessary to setup request scoped variables) doesn't cause incorrectly saved state. The row index must have been changed to a row that has not been visited yet (in the case of the 0th row), to cause state saving for the parent, and the change to the 0th row of the expanded set causes state saving for that hack row change.
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #28580 Thu Mar 29 09:48:55 MDT 2012 nils.lundquist ICE-7959 - Fixed MyFaces state saving by forcing row changes to the integer value max row
        Files Changed
        Commit graph MODIFY /icefaces3/branches/icefaces-3.0.x-maintenance/icefaces/ace/component/src/org/icefaces/ace/component/datatable/DataTable.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #28582 Thu Mar 29 09:51:36 MDT 2012 nils.lundquist ICE-7959 - Fixed MyFaces state saving by forcing row changes to the integer value max row prior to changing into a tree case and prior to returning from a tree case. Also prevented the visitTree from accidentally skipping the row following the return from a row expansion, row index was incremented by tree case and base case.
        Files Changed
        Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/datatable/DataTable.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #28583 Thu Mar 29 10:26:02 MDT 2012 nils.lundquist ICE-7959 - Fixed MyFaces state saving equivalently when iterate is used to traverse DT rows, as opposed to visitTree.
        Files Changed
        Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/datatable/DataTable.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #28585 Thu Mar 29 10:55:29 MDT 2012 nils.lundquist ICE-7959 - Fixed MyFaces state saving equivalently when iterate is used to traverse DT rows as opposed to visitTree
        Files Changed
        Commit graph MODIFY /icefaces3/branches/icefaces-3.0.x-maintenance/icefaces/ace/component/src/org/icefaces/ace/component/datatable/DataTable.java
        Hide
        Nils Lundquist added a comment -

        Overcame issue by changing row index to the integer maximum value prior to moving into a set of subrows, and prior to returning to a set of super-rows. Also fixed a compounding bug with RowState loading during visiting of the expanded rows.

        Show
        Nils Lundquist added a comment - Overcame issue by changing row index to the integer maximum value prior to moving into a set of subrows, and prior to returning to a set of super-rows. Also fixed a compounding bug with RowState loading during visiting of the expanded rows.
        Nils Lundquist made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 3.1 [ 10312 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Salesforce Case []
        Component/s ACE-Components [ 10050 ]
        Affects Version/s 3.0.1 [ 10282 ]
        Ken Fyten made changes -
        Salesforce Case []
        Fix Version/s EE-3.0.0.GA_P01 [ 10327 ]
        Ken Fyten made changes -
        Salesforce Case []
        Fix Version/s 3.1.0.BETA1 [ 10335 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: