Details
New Feature
Description
Brought about because of ICE-9146, there is the issue where EditableValueHolders do not state save their submitted values, so after a lifecycle that was invalid, if the next lifecycle is due to an ajax call that only executes certain component(s) but renders all or at least ones that were not executed, then those unexecuted and rendered components will glitch where they will have lost their submitted values, and did not decode to pickup again their submitted values, so they will then render their previous values.
Ideally, those unexecuting EditableValueHolders could just decode their submitted values, and do no further processing, so that they would render correctly.
Alternatively, much like the FacesMessagePhaseListener (ICE-5750, ICE-6820, ICE-7137), we could propagate the submitted values forward, and set them before the ApplyRequestValues phase, so that any newly submitted values would then take over. They could explicitly be saved at the end of the previous lifecycle and restored in the subsequent lifecycle, and saved in flash scope inbetween. Potentially the RequestParameterMap could simply be used, but there are cases like checkbox components, where the raw string is mutated before being set into the submitted value. There could be an algorithm that only saves into flash the objects that are not the exact strings found in the previous RequestParameterMap, so that the saved state is as small as possible, and then the restoration would comes from both the new RequestParameterMap and the saved submitted values, with the saved submitted values taking precedence.
Ideally, those unexecuting EditableValueHolders could just decode their submitted values, and do no further processing, so that they would render correctly.
Alternatively, much like the FacesMessagePhaseListener (
Issue Links
- blocks
-
ICE-9146
textAreaEntry submittedValue is getting lost by the drop-down execute
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Mircea Toma [ mircea.toma ] | |
| Fix Version/s | 3.4 [ 10770 ] | |
| Affects | Documentation (User Guide, Ref. Guide, etc.),Sample App./Tutorial [ 10003, 10001 ] | |
| Assignee Priority | P3 [ 10012 ] |
JSF 2.2 has an improvement that might impact this discussion. See http://jdevelopment.nl/jsf-22/ , then search for the first occurrence of "validation" in the page.
I still believe my analysis is correct but trying to fix the problem would require a potentially serious performance penalty.
A workaround for this issue is possible when using JSF 2.2 or higher. The resetValues=true attribute on the f:ajax or f:resetValues facet can be used to reset the submitted values so that the client and server do not get out of sync. See also ICE-9513.
Show
Mircea Toma
added a comment - I still believe my analysis is correct but trying to fix the problem would require a potentially serious performance penalty.
A workaround for this issue is possible when using JSF 2.2 or higher. The resetValues=true attribute on the f:ajax or f:resetValues facet can be used to reset the submitted values so that the client and server do not get out of sync. See also ICE-9513.
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Won't Fix [ 2 ] |
| Fix Version/s | 4.0 [ 11382 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
After analysing how JSF+f:ajax vs ICEfaces+JSF behave I can state that the difference is caused by our DOMPartialViewContext.applyBrowserChanges method. This method changes the values of the different form elements found in the old DOM to match the values that the browser has after a submit. This is to avoid generating updates for the modified elements, updates that would just re-apply the same values that already were entered by the user.
When validation fails the newly received values are not applied, so after the render phase when the new DOM is generated the document will not contain these new values. On the other hand the old DOM will be updated by DOMPartialViewContext.applyBrowserChanges method who does not do any validation on the parameters it works with. In the end the dom diff sees the difference between the old and new DOM, and it will generate updates with the old values.
These updates are the ones that change the behaviour of ICEfaces+JSF because they revert the values of the form elements to how they were before the user changed and submitted the new values.