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.
Bug
Major
ADD
/icefaces2/trunk/icefaces/samples/core/test/fajax/src/main/webapp/disabledCommandLinks.xhtml
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.