Details
-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.7.1
-
Component/s: ICE-Components
-
Labels:None
-
Environment:All
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial
Description
Throughout the forums, users are complaining about the fact that ValueChangeEvents happen before UPDATE_MODEL_VALUES, so if they programmatically set the values for other input components, then those values will be stomped over with the decoded (converted and validated) values. There are two main solutions, to clear out the submitted values on the target components, or to re-queue the ValueChangeEvent to INVOKE_APPLICATION, which requires bean code modifications.
What would be simpler is to add a component, ice:eventSetPhase, which could override UIComponentBase.queueEvent(FacesEvent), and reset the PhaseId on the FacesEvents passing through. That way, ValueChangeEvents from child components could be flipped to INVOKE_APPLICATION.
By default it would change all FacesEvents to INVOKE_APPLICATION, but it would have two attributes to optionally constrain this behaviour. The "events" attribute would be a space delimited list of class types to act on, and the "phase" attribute would be the PhaseId to set the FacesEvents to.
Here's a discussion on the topic in the JSF RI dev mailing list:
https://javaserverfaces.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1750
What would be simpler is to add a component, ice:eventSetPhase, which could override UIComponentBase.queueEvent(FacesEvent), and reset the PhaseId on the FacesEvents passing through. That way, ValueChangeEvents from child components could be flipped to INVOKE_APPLICATION.
By default it would change all FacesEvents to INVOKE_APPLICATION, but it would have two attributes to optionally constrain this behaviour. The "events" attribute would be a space delimited list of class types to act on, and the "phase" attribute would be the PhaseId to set the FacesEvents to.
Here's a discussion on the topic in the JSF RI dev mailing list:
https://javaserverfaces.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1750
Activity
Mark Collette
created issue -
Mark Collette
made changes -
Field | Original Value | New Value |
---|---|---|
Description |
Throughout the forums, users are complaining about the fact that ValueChangeEvents happen before UpdateModel, so if they programmatically set the values for other input components, then those values will be stomped over with the decoded (converted and validated) values. There are two main solutions, to clear out the submitted values on the target components, or to re-queue the ValueChangeEvent to InvokeApplication, which requires bean code modifications. What would be simpler is to add a component, ice:eventSetPhaseId, which could override UIComponentBase.queueEvent(FacesEvent), and reset the PhaseId on the FacesEvents passing through. That way, ValueChangeEvents from child components could be flipped to InvokeApplication. By default it would change all FacesEvents to InvokeApplication, but it would have two attributes to optionally constrain this behaviour. The "events" attribute would be a comma delimited list of class types to act on, and the "phaseId" attribute would be the PhaseId to set the FacesEvents to. |
Throughout the forums, users are complaining about the fact that ValueChangeEvents happen before UpdateModel, so if they programmatically set the values for other input components, then those values will be stomped over with the decoded (converted and validated) values. There are two main solutions, to clear out the submitted values on the target components, or to re-queue the ValueChangeEvent to InvokeApplication, which requires bean code modifications. What would be simpler is to add a component, ice:eventSetPhaseId, which could override UIComponentBase.queueEvent(FacesEvent), and reset the PhaseId on the FacesEvents passing through. That way, ValueChangeEvents from child components could be flipped to InvokeApplication. By default it would change all FacesEvents to InvokeApplication, but it would have two attributes to optionally constrain this behaviour. The "events" attribute would be a comma delimited list of class types to act on, and the "phaseId" attribute would be the PhaseId to set the FacesEvents to. Here's a discussion on the topic in the JSF RI dev mailing list: https://javaserverfaces.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1750 |
Security | Private [ 10001 ] | |
Assignee | Mark Collette [ mark.collette ] |
Ken Fyten
made changes -
Fix Version/s | 1.8DR#2 [ 10142 ] |
Ken Fyten
made changes -
Fix Version/s | 1.8DR#3 [ 10143 ] | |
Fix Version/s | 1.8DR#2 [ 10142 ] |
Ken Fyten
made changes -
Salesforce Case | [] | |
Affects | [Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial] | |
Assignee Priority | P2 |
Ken Fyten
made changes -
Salesforce Case | [] | |
Security | Private [ 10001 ] |
Mark Collette
made changes -
Summary | ice:eventSetPhaseId | ice:eventSetPhase |
Salesforce Case | [] | |
Description |
Throughout the forums, users are complaining about the fact that ValueChangeEvents happen before UpdateModel, so if they programmatically set the values for other input components, then those values will be stomped over with the decoded (converted and validated) values. There are two main solutions, to clear out the submitted values on the target components, or to re-queue the ValueChangeEvent to InvokeApplication, which requires bean code modifications. What would be simpler is to add a component, ice:eventSetPhaseId, which could override UIComponentBase.queueEvent(FacesEvent), and reset the PhaseId on the FacesEvents passing through. That way, ValueChangeEvents from child components could be flipped to InvokeApplication. By default it would change all FacesEvents to InvokeApplication, but it would have two attributes to optionally constrain this behaviour. The "events" attribute would be a comma delimited list of class types to act on, and the "phaseId" attribute would be the PhaseId to set the FacesEvents to. Here's a discussion on the topic in the JSF RI dev mailing list: https://javaserverfaces.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1750 |
Throughout the forums, users are complaining about the fact that ValueChangeEvents happen before UPDATE_MODEL_VALUES, so if they programmatically set the values for other input components, then those values will be stomped over with the decoded (converted and validated) values. There are two main solutions, to clear out the submitted values on the target components, or to re-queue the ValueChangeEvent to INVOKE_APPLICATION, which requires bean code modifications. What would be simpler is to add a component, ice:eventSetPhase, which could override UIComponentBase.queueEvent(FacesEvent), and reset the PhaseId on the FacesEvents passing through. That way, ValueChangeEvents from child components could be flipped to INVOKE_APPLICATION. By default it would change all FacesEvents to INVOKE_APPLICATION, but it would have two attributes to optionally constrain this behaviour. The "events" attribute would be a space delimited list of class types to act on, and the "phase" attribute would be the PhaseId to set the FacesEvents to. Here's a discussion on the topic in the JSF RI dev mailing list: https://javaserverfaces.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1750 |
Mark Collette
made changes -
Summary | ice:eventSetPhase | ice:setEventPhase |
Salesforce Case | [] |
Mark Collette
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Ken Fyten
made changes -
Fix Version/s | 1.8 [ 10161 ] | |
Assignee Priority | P2 |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
Assignee | Mark Collette [ mark.collette ] |
From discussion, we'll make it do nothing by default, and you have to specify the events and phase to make it do anything, that way applications can use ValueBindings for those attributes, to enable/disable it if need be. Plus, the whole idea is to make things more declarative, and default actions are not declarative.
In deciding between calling this component <ice:eventSetPhase> and <ice:setEventPhase>, I'm going with <ice:setEventPhase>, since it flows better, and is more consistent with the naming of othe JSF tags, like <f:setPropertyActionListener>.