Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.0.1
-
Fix Version/s: 3.1.0.BETA1, 3.1, EE-3.0.0.GA_P01
-
Component/s: ACE-Components
-
Labels:None
-
Environment:IF 3.x
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.
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
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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.