Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.2
-
Fix Version/s: 1.8.2-EE-GA_P01, 1.8.3
-
Component/s: ICE-Components
-
Labels:None
-
Environment:All
-
ICEsoft Forum Reference:
Description
In a standard web page, or stock JSF application, if there is a form, input fields, and a submit button, and the user presses enter in one of the input fields, the form will be submitted as if the submit button has been pressed. In stock JSF applications, that results in the submit commandButton's action or actionListener being invoked. Application developers would like that capability in ICEfaces applications.
Currently, ICEfaces intercepts all form submissions, to be able to do its own form field serialization, and bundle in ICEfaces specific submitted values. This keeps the browser's default behaviour from happening. When seeking to address user's desire of default browser behaviour, it's been noted that certain issues make it suboptimal. For example, in stock JSF applications, if there are multiple submit buttons, then there is not consistent behaviour across browsers, as to which submit button will be virtually clicked. Solving the simple case would likely break more complex cases. Furthermore, after DOM manipulation, which submit button is clicked becomes arbitrary in some browsers. There is also the question of forms with input fields, and no submit button, which is quite popular with search fields.
Historically, ICEfaces addressed these issues by allowing applications to specify an action/actionListener on certain input fields directly, so that if ENTER was pressed in that specific input field, a precisely specified action/actionListener could be invoked. This fine grained control becomes a detriment when there are many input fields in a form, or when using multiples levels of JSP or Facelets inclusion, and the application wishes to always invoke the same action/actionListener.
So, to complement existing behaviours, we propose adding action and actionListener attributes to ice:form, so that there may be a single place to specify the action/actionListener, regardless of the submitting component, whether it be an input field or UICommand subclass like commandButton. When any of those components cause a full form submission (not a partialSubmit), they will be given a chance to invoke their own action/actionListener, but if they have none specified, then the ice:form will invoke its own action/actionListener, if one was specified. In this way, a catch-all action/actionListener may be specified on the ice:form, which can be overridden on a per component basis.
Currently, ICEfaces intercepts all form submissions, to be able to do its own form field serialization, and bundle in ICEfaces specific submitted values. This keeps the browser's default behaviour from happening. When seeking to address user's desire of default browser behaviour, it's been noted that certain issues make it suboptimal. For example, in stock JSF applications, if there are multiple submit buttons, then there is not consistent behaviour across browsers, as to which submit button will be virtually clicked. Solving the simple case would likely break more complex cases. Furthermore, after DOM manipulation, which submit button is clicked becomes arbitrary in some browsers. There is also the question of forms with input fields, and no submit button, which is quite popular with search fields.
Historically, ICEfaces addressed these issues by allowing applications to specify an action/actionListener on certain input fields directly, so that if ENTER was pressed in that specific input field, a precisely specified action/actionListener could be invoked. This fine grained control becomes a detriment when there are many input fields in a form, or when using multiples levels of JSP or Facelets inclusion, and the application wishes to always invoke the same action/actionListener.
So, to complement existing behaviours, we propose adding action and actionListener attributes to ice:form, so that there may be a single place to specify the action/actionListener, regardless of the submitting component, whether it be an input field or UICommand subclass like commandButton. When any of those components cause a full form submission (not a partialSubmit), they will be given a chance to invoke their own action/actionListener, but if they have none specified, then the ice:form will invoke its own action/actionListener, if one was specified. In this way, a catch-all action/actionListener may be specified on the ice:form, which can be overridden on a per component basis.
-
Hide
-
-
META-INF/MANIFEST.MF
-
WEB-INF/classes/bean/Employee.class
-
index.jsp
-
WEB-INF/lib/xercesImpl.jar
-
WEB-INF/lib/icefaces-comps.jar
-
WEB-INF/classes/bean/Bean.class
-
WEB-INF/lib/commons-collections.jar
-
WEB-INF/lib/backport-util-concurrent.jar
-
WEB-INF/classes/bean/Bean.java
-
WEB-INF/lib/commons-beanutils.jar
-
WEB-INF/lib/commons-logging.jar
-
WEB-INF/lib/jstl.jar
-
main.jspx
-
WEB-INF/.../krysalis-jCharts-1.0.0-alpha-1.jar
-
WEB-INF/classes/bean/Employee.java
-
WEB-INF/web.xml
-
WEB-INF/lib/xml-apis.jar
-
WEB-INF/lib/icefaces.jar
-
WEB-INF/lib/commons-digester.jar
-
WEB-INF/lib/jsf-api.jar
-
WEB-INF/lib/jsf-impl.jar
-
WEB-INF/lib/commons-fileupload.jar
-
WEB-INF/faces-config.xml
-
-
-
Hide
-
-
META-INF/MANIFEST.MF
-
WEB-INF/classes/bean/Bean.class
-
WEB-INF/classes/bean/Bean.java
-
WEB-INF/classes/bean/Employee.class
-
WEB-INF/classes/bean/Employee.java
-
WEB-INF/faces-config.xml
-
WEB-INF/lib/FastInfoset.jar
-
WEB-INF/lib/backport-util-concurrent.jar
-
WEB-INF/lib/commons-beanutils.jar
-
WEB-INF/lib/commons-collections.jar
-
WEB-INF/lib/commons-digester.jar
-
WEB-INF/lib/commons-discovery.jar
-
WEB-INF/lib/commons-el.jar
-
WEB-INF/lib/commons-fileupload.jar
-
WEB-INF/lib/commons-logging.jar
-
WEB-INF/lib/icefaces-comps.jar
-
WEB-INF/lib/icefaces.jar
-
WEB-INF/lib/jsf-api-1.2.jar
-
WEB-INF/lib/jsf-impl-1.2.jar
-
WEB-INF/lib/jstl.jar
-
buttonAction.jspx
-
formAction.jspx
-
index.jsp
-
linkAction.jspx
-
main.jspx
-
textAction.jspx
-
WEB-INF/web.xml
-
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
war file for demo showing form and component actions: ICE-5122-2.war
More restricted, so the form should only take over on ActionEvent if the form component is defining either an "action" or an "actionListener".
Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\HtmlForm.java
Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\HtmlForm.java
Completed: At revision: 19881
Show
Adnan Durrani
added a comment - More restricted, so the form should only take over on ActionEvent if the form component is defining either an "action" or an "actionListener".
Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\HtmlForm.java
Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\HtmlForm.java
Completed: At revision: 19881
The following two attributes are added to the form component:
- action
- actionListener
To fix this issue, the changes has been made so the form component can takeover on ActionEvent if the real source of the event doesn't provide any action or actionListener (e.g.)
//in this example inputText will process the event, when hitting enter on inputText
<ice:form>
<ice:inputText actionListener="#
//in this example again the inputText will process the event, when hitting enter on inputText
<ice:form actionListener="#{bean.formListener}">
<ice:inputText actionListener="#{bean.textListener}
" />
//in this example due to the absence of actionListener on inputText, the form will process the event, when hitting enter on inputText.
<ice:form actionListener="#
">
<ice:inputText />
Please see attached demos for more detail.
Show
Adnan Durrani
added a comment - The following two attributes are added to the form component:
action
actionListener
To fix this issue, the changes has been made so the form component can takeover on ActionEvent if the real source of the event doesn't provide any action or actionListener (e.g.)
//in this example inputText will process the event, when hitting enter on inputText
<ice:form>
<ice:inputText actionListener="#
{bean.textListener}" />
//in this example again the inputText will process the event, when hitting enter on inputText
<ice:form actionListener="#{bean.formListener}">
<ice:inputText actionListener="#{bean.textListener}
" />
//in this example due to the absence of actionListener on inputText, the form will process the event, when hitting enter on inputText.
<ice:form actionListener="#
{bean.formListener}
">
<ice:inputText />
Please see attached demos for more detail.
This scenario
//in this example again the inputText will process the event, when hitting enter on inputText <ice:form actionListener="#{bean.formListener}"> <ice:inputText actionListener="#{bean.textListener}" />
not works in http://anonsvn.icesoft.org/repo/icefaces/trunk/icefaces rev. 32567. Only form action listener is fired.
Show
Krashan Brahmanjara
added a comment -
This scenario
//in this example again the inputText will process the event, when hitting enter on inputText
<ice:form actionListener= "#{bean.formListener}" >
<ice:inputText actionListener= "#{bean.textListener}" />
not works in http://anonsvn.icesoft.org/repo/icefaces/trunk/icefaces rev. 32567. Only form action listener is fired.
We've identified two main strategies for accomplishing this.
One strategy would be to modify each ice: component that can specify an action or actionListener, and make it so that where they decide if they are responsible for creating an ActionEvent, to check if an action/actionListener is specified on them, and if so create their own ActionEvent, and otherwise find their form, and if it's an ice:form, allow that to create an ActionEvent if it has an action or actionListener specified on it. This wouldn't work with third party components, and in the case of the h: components would result in the stock browser behaviour, instead of the ice:form specified one.
Another strategy would be to modify ice:form to detect when a full form submission has occurred, where none of its children had queued an ActionEvent, and then queue one itself, if it has an action/actionListener. This would involve overriding HtmlForm's queueEvent
and processDecodes
methods, so as to track if queueEvent had been called with an ActionEvent, while processDecodes
was recursing through the child components, which is when they could enqueue an ActionEvent. At the end of processDecodes
, if no child had enqueued an ActionEvent, then HtmlForm could do so itself, if it had an action/actionListener and if it was a full form submit. The problem here is that if the child component that does enqueue an ActionEvent is within a UIData or ICEfaces UISeries, then the ActionEvent will be wrapped inside another FacesEvent, which contains the UIData/UISeries row information. Even if we allow for inspection within ICEfaces' row events, that still doesn't cover the UIData wrapper event. Introspection could be added in that case. Still, any third party container component that uses event wrapping would break this feature.