From what I understand, we don't support f:ajax within ACE components. And when you wrap a block of components with f:ajax, it's as if you put the f:ajax with every component in that block that is a ClientBehaviorHolder that supports the eventName that the f:ajax is using. So really it's not valid to wrap ACE components with an f:ajax.

If there is some scenario where we're trying to make the f:ajax only apply to some h: components in the block and not any ACE components, then I would first examine if an event name had been specified, instead of being set to null, so that could keep it from being set on the ACE components, which hopefully wouldn't share that event name. If that's not doable, then we could modify the ACE generator so that our generated Base classes, which are ClientBehaviorHolder implementators, would override UIComponentBase.addClientBehavior(String eventName, ClientBehavior behavior) to specifically not add javax.faces.component.behavior.AjaxBehavior, while allowing org.icefaces.ace.component.ajax.AjaxBehavior.

In CoreRenderer, there are noticeable differences between
encodeClientBehaviors(FacesContext context, ClientBehaviorHolder component, JSONBuilder jb)
and
encodeClientBehaviors(FacesContext context, ClientBehaviorHolder component)

Unfortunately, the JSONBuilder version that most of our components use handles things worse than the ResponseWriter one. For a given event, there may be no ClientBehavior(s), there may be one, or there may be several, any may be disabled, and any of them may be f:ajax, which we attempt to ignore. The ResponseWriter code handles there being none, there being noe that are enabled, and there being none that are not f:ajax equivalently, and won't output the event key/value pair. The JSONBuilder one confuses those scenarios, and so can render the key/value pair when there is no value due to eliminating the f:ajax.

As well, there is the issue of the ResponseWriter omitting the key/value pair when there is no javascipt, and the JSONBuilder trying to render a key/value pair with a value of undefined when there is no javascript. It's not clear to me which is better. Only that omitting uses less bandwidth.

From talking with Nils, we'll go with omitting.

Another reason to not allow adding f:ajax at all to ACE components, is that there's a possibility that it will decode and queue/broadcast events when the ACE component has an ace:ajax submit, if the event names happen to match up.

Fixed ACE CoreRenderer so it will not render the event/script key/value pair if the script isn't valid.

trunk
Subversion 29556

Merged the change to the maintenance branch, which required a bit of an adaptation, since some dependent code wasn't there.

icefaces3-maintenance
Subversion 30622

Now, if f:ajax is added inside an ACE component, or wraps it, it just won't be added to the component at all.

Augmented the generator and ClientBehaviorHolder annotation to support the new allowFAjax field. By default it's false, and so results in the Base class overriding addClientBehavior(String eventName, ClientBehavior behavior) and not allowing an exact class match of javax.faces.component.behavior.AjaxBehavior, that f:ajax adds. This way, if third parties using ACEnvironment want their components to work with f:ajax they can, while our ACE components won't. And if we ever need to sub-class javax.faces.component.behavior.AjaxBehavior to use it for something, then that will work too.

Fixed up some whitespace and code placement in the generated Base classes while I was in there.

trunk
Subversion 29557

icefaces3-maintenance
Subversion 30623

We can verify the f:ajax AjaxBehavior class isn't being added at all anymore by seeing this:

Map<String,List<ClientBehavior>> behaviorEvents = component.getClientBehaviors();
System.out.println("behaviorEvents: " + behaviorEvents);

The output used to look like this:

behaviorEvents:

Now it looks like this:

behaviorEvents: {}

Backported, and original comments edited to reflect the maintenance branch subversion numbers.