Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: EE-3.3.0.GA_P01
-
Fix Version/s: EE-3.3.0.GA_P03, 4.1
-
Component/s: Sample Apps
-
Labels:None
-
Environment:Tomcat 7, all browsers, deltaSubmit=true, showcase dataTable > Row State, Row/Cell editing demos
-
Assignee Priority:P1
Description
After editing a cell and submitting changes the new input is reverted back to the original value.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Added 4.1 target, since this issue is also reproducible on the 4.x trunk.
The problem seems to be that the parameters with the remove prefix ('patch-') are not being included in the delta submit request for any input fields inside cell editors, unlike other input fields that are always visible. When I artificially added the corresponding 'patch-' parameter for a specific field that was edited, the new value was saved successfully and the table cell displayed the value just entered, instead of reverting to the original value.
Committed fix to the 3.3 EE maintenance branch at revision 44702 and to the P03 tag at revision 44701. The fix consists in adding 'patch-' parameters to the request, corresponding to input fields inside cell editors whose value changed, when deltaSubmit=true.
Committed fix to the 4.x trunk at revision 44703.
Verified ICEfaces EE-3.3.0.GA_P03 tag, EE-maintenance branch r44706, Tomcat 7, IE 11, 10, 9, 8, 7, Chrome 42, FF 34.
When tested with ICEfaces 4 trunk the new data could not be submitted and a console error appears. This is an issue whether deltaSubmit is set to true or false.
ReferenceError: changes is not defined
http://localhost:8080/showcase/javax.faces.resource/bridge.js.jsf?ln=ice.core&v=4_1_0_150519 line 2 > eval
Line 139
r44707: made a correction to the fix on the 4.x trunk.
Verified ICEfaces 4 trunk r44708, Tomcat 7, IE 11, FF 34, Chrome 42.
Verified ICEfaces EE-3.3.0.GA_P03 Jenkins build 08, Tomcat 7, IE 11, 10, 9, 8, 7, Chrome 42, FF 34
After substantial investigation, it's still not clear what exactly is causing this issue. This issue can also be seen in the P02, P01 and the original 3.3.0 release in the Row State demo only when enabling rows for editing by clicking the buttons above the table. The requests made when deltaSubmit=true are correct, and they contain the new values entered when editing, but in the decoding phase the submitted value (retrieved from the request parameters map, using the component's client id as a key) is always the previous value, and not what was edited in the text field and sent in the request. This also occurs with other input components. It seems like the internal mechanism used by delta submit to compare previous values is reverting the values sent in the request, under certain scenarios.