Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.2
-
Fix Version/s: 3.0.RC2, 3.0, EE-2.0.0.GA_P01
-
Component/s: Bridge, Framework, ICE-Components
-
Labels:None
-
Environment:ICEfaces 2
-
Assignee Priority:P1
-
Affects:Compatibility/Configuration
-
Workaround Exists:Yes
-
Workaround Description:Where possible, use <f:ajax disabled="true"> with h:commandButton instead of h:commandLink.
Description
There are use cases where it's desirable to disable Ajax request processing for specific components. Since ICEfaces automatically enables Ajax for stock components and components that adhere to standard JSF APIs, the recommended strategy is to disable ajax using <f:ajax disabled="true">.
Testing of the current trunk shows that this technique is currently working for h:commandButtons but not for h:commandLinks.
Testing of the current trunk shows that this technique is currently working for h:commandButtons but not for h:commandLinks.
Issue Links
- blocks
-
ICE-7405
Setting <f:ajax disabled="true"> does not work for h:commandLink and h:commandButton having an f:param
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
There are a number of different cases that have touched on the subject of using <f:ajax disabled="true">. I've attempted to summarize the history here and provide relevant links.
The original JIRA for supporting <f:ajax disabled="true"> is http://jira.icefaces.org/browse/ICE-5651. Work was done here to add logic into the FormSubmit event listener to add a hidden input field with ids for each component (or all the components in a form) that have Ajax turned off. The last comment in this case suggest that commandLink was eventually supported at some point.
Later, another JIRA for <f:ajax disabled="true"> not working correctly http://jira.icefaces.org/browse/ICE-6717 was opened by a user and noted some scenarios where the attribute wasn't functioning properly. Judging from the comments, the additional work to fix this was only confirmed against h:commandButtons. A JIRA was also opened in the Mojarra system (http://java.net/jira/browse/JAVASERVERFACES-2041) about problems using f:ajax with ui:includes. The case remains unresolved and the last comment on June 6, 2011 is:
"This also affects 2.0.5, and basically borks all ajax calls after the first one when using facelets templates, thus rendering the ajax functionality of JSF basically useless. This is a pretty serious bug."
Additional work for http://jira.icefaces.org/browse/ICE-6327 was done to try to improve commandButtons and commandLinks that have f:params associated with them as these component will decorate the onClick handler with a Mojarra JS call that adds in the extra parameters like this:
<a href="#" id="link1" onclick="mojarra.jsfcljs(document.getElementById('form1'),
{'link1':'link1','commandparam':'linkparam'},'');return false">Show/Hide</a>
It's possible this same issue is responsible for the issues we continue to see with h:commandLinks. There were also comments to the effect that the f:ajax setting does not/ can not directly affect h:forms, only the components inside the form.
The case http://jira.icefaces.org/browse/ICE-6685 was opened by a user and refers to <f:ajax disabled="true"> not working with ace:pushButton.
The cases http://jira.icefaces.org/browse/ICE-6806 and http://jira.icefaces.org/browse/ICE-6814 refer to compatibility of the PrimeFaces FileDownload and DataExporter components with ICEfaces 2. Ted recommended using <f:ajax disabled="true"> but it didn't seem to work. Other approaches/code changes were discussed based on mobility work. This still didn't solve the problem for h:commandLink.