<f:ajax> is described in the JSF 2.0 specification section 10.4.1.1 table 10-3.

For the disabled attribute in particular:

"false" indicates the Ajax behavior script should be rendered; "true" indicates the Ajax behavior script should not be rendered. "false" is the default.

The following code dumps out the disabled state of the ajax behavior attached to a given component:

import javax.faces.component.UIComponentBase;
import javax.faces.component.behavior.ClientBehavior;
import javax.faces.component.behavior.AjaxBehavior;

Map <String, List <ClientBehavior>> behaviors = ((UIComponentBase) component).getClientBehaviors();
AjaxBehavior behavior = (AjaxBehavior) behaviors.get("action").get(0);
System.out.println("behaviors found " + behaviors);
System.out.println("behavior " + behavior + " " + behavior.isDisabled());

So, the <f:ajax> tag is not directly accessible itself, but it creates the AjaxBehavior Object attached to the component which does have an extensive API.

Actual use of this API would need to iterate over all component behaviors and test for AjaxBehavior instances.

This appears to work for both the nested and the wrapping forms:

<f:ajax execute="button1" render="pg1 pg2" >
<h:commandButton id="button1" value="Show/Hide"
actionListener="#

" >
<f:ajax execute="button1" render="pg1 pg2" />
</h:commandButton>

<f:ajax disabled="true"/> must cause the "capture submit" behavior of the ICEfaces bridge to be disabled for that one component.

HTML5 supports custom data-* attributes (which are frowned upon but not actually prohibited in HTML currently):

http://dev.w3.org/html5/spec/elements.html#embedding-custom-non-visible-data

For instance the bridge callback added by ice.captureSubmit() could check for the presence of data-ice-ajax="disabled" on the submitting element, and if present allow full-page form submission to proceed normally.

Alternatively, the component could render JavaScript event callbacks that would set a flag, however this would result in verbose markup due to the variety of events that can cause form submission to occur.

Part of the change to application.js required that the onsubmit callback not always be erased; it's not clear why this was necessary before.

— core/src/main/javascript/application.js (revision 21816)
+++ core/src/main/javascript/application.js (working copy)
@@ -169,16 +169,21 @@
f.submit = function()

;

• f.onsubmit = none;
  +// f.onsubmit = none;
  each(['onkeydown', 'onkeypress', 'onkeyup', 'onclick', 'ondblclick', 'onchange'], function(name) {
  f[name] = function(e) {
  var event = e || window.event;

Is the f.onsubmit = none necessary in some conditions?

Server code takes UINamingContainer.getSeparatorChar() into account, but client-side script does not. Perhaps this is available from the jsf.js API. If not, it should be.

Theoretically, it seems that 'f.onsubmit = none' is not necessary. There are certain events (within certain browsers) that are not canceling the default action even if they are told so. See 'click' event for example, 'Prevent Default' section: http://www.quirksmode.org/dom/events/click.html .
Also, to avoid any browser specific issues the 'onsubmit' is disabled in case the 'submit' event is generated by the browser during capturing phase instead of bubbling phase. See: http://www.quirksmode.org/js/events_order.html .

Can we reproduce a problem in a certain browser with that line commented out? It will make the f:ajax disabled more complex to implement (we will need to conditionally set f.onsubmit to none in both places).

<f:ajax disabled="true"> has no effect in basic, but is verified working in auction.

commandLink is not currently functional: the "onclick" is being handled by the span contained within the commandLink, so is not found in the "disabled" list.

Verified successfully the reload button on the icefaces.jsf page using

Glimmer revision 21833
Servers: Tomcat 6.0.26, Glassfish v3 with Mojarra 2.0.2 jars
Browsers: FF3.6, IE8

commandLink is now supported.

Note that <f:ajax disabled="false"> will often have undesirable side effects – this will result in the JSF 2.0 Ajax defaults being applied (such as execute and render "this").

Optimizations are possible beyond the current implementation: when detecting commandLink, all disabled elements are tested for the existence of hidden fields with that identical name and value. This could be restricted to commandLink elements only.