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