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
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
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Made the setEventPhase component, its metadata, documentation, and added it to the JSP, Facelets, Facelets-enh, Portlets component-showcase.
Subversion 18241
icefaces\component-metadata\src\main\resources\conf\custom\setEventPhase-component.xml
icefaces\component-metadata\src\main\resources\conf\custom\setEventPhase-renderer.xml
icefaces\component-metadata\src\main\resources\conf\ice\components\SetEventPhase-component.xml
icefaces\component-metadata\src\main\resources\conf\ice_cust_properties\cust-setEventPhase-props.xml
icefaces\component\doc\en\setEventPhase.html
icefaces\component\doc\es\setEventPhase.html
icefaces\component\doc\setEventPhase.html
icefaces\component\src\com\icesoft\faces\component\seteventphase\SetEventPhase.java
icefaces\samples\component-showcase\common-src\org\icefaces\application\showcase\view\bean\examples\component\setEventPhase\SetEventPhaseBean.java
icefaces\samples\component-showcase\common-web\WEB-INF\includes\examples\custom\setEventPhase.jspx
icefaces\samples\component-showcase\portlets\web\Components_SetEventPhase.jspx
icefaces\component-metadata\src\main\resources\conf\extended-faces-config.xml
icefaces\component-metadata\src\main\resources\conf\faces-config-base.xml
icefaces\component-metadata\src\main\resources\conf\faces-config.xml
icefaces\component\conf\META-INF\facelet\icefaces.taglib.xml
icefaces\samples\component-showcase\common-src\org\icefaces\application\showcase\view\resources\messages_en.properties
icefaces\samples\component-showcase\common-src\org\icefaces\application\showcase\view\resources\messages_es.properties
icefaces\samples\component-showcase\common-web\WEB-INF\faces-config-example-beans.xml
icefaces\samples\component-showcase\facelets-enh\src\org\icefaces\application\showcase\view\jaxb\resources\application_structure.xml
icefaces\samples\component-showcase\facelets-enh\src\org\icefaces\application\showcase\view\jaxb\resources\application_structure_en.xml
icefaces\samples\component-showcase\facelets-enh\src\org\icefaces\application\showcase\view\jaxb\resources\application_structure_es.xml
icefaces\samples\component-showcase\facelets\web\WEB-INF\includes\content\navigation.jspx
icefaces\samples\component-showcase\jsp\web\showcase.jspx
icefaces\samples\component-showcase\jsp\web\WEB-INF\includes\content\navigation.jspx
icefaces\samples\component-showcase\portlets\conf\liferay\liferay-display.xml
icefaces\samples\component-showcase\portlets\conf\liferay\liferay-portlet.xml
icefaces\samples\component-showcase\portlets\conf\portlet.xml
BTW
Current example from component-showcase doesn't show results of this feature. I mean results with this feature andt without. The same working example exist in Selection example.
Yes, we don't have an example of how, without this tag, the code would be broken. I'm not sure that people would understand an application misbehaving, as an example. But what is does demonstrate, is how much simpler this tag is, than the work-arounds used in the Selection example. Both are valid ways of solving the problem, but setEventPhase is simpler, doesn't require any bean code, and is more declarative.
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>.