> Does this mean there is now a way to specify that some forms are icefaces and others are not within the same servlet/portlet?

No, right now all the forms within a page or portlet are ICEfaces enabled. We haven't had any real world use cases where the ICEfaces features would be enabled with finer detail.

> Or does the inclusion of icefaces.jar in the .war itself mean that all the forms on that servlet/portlet are icefaces forms?

Yes, it does. Still, input components can have their AJAX submit disabled with <f:ajax disabled="true"> tag.

> Also, is this fix available or do I need to wait until the 2.1 release?

The fix is available in the public SVN repository. Officially it will be part of 2.1 release.

> Is there a projected timeline for that release?

End of October, I believe.

Does this mean there is now a way to specify that some forms are icefaces and others are not within the same servlet/portlet? Or does the inclusion of icefaces.jar in the .war itself mean that all the forms on that servlet/portlet are icefaces forms? Also, is this fix available or do I need to wait until the 2.1 release? Is there a projected timeline for that release?

Introduced event filtering function that allows the invocation of ICEfaces callbacks only when the submitted form is ICEfaces enabled.

Need to revert these changes as we require the ICEfaces callbacks to be invoke via regular JSF for none-portlet scenarios.

A refined solution will need to be found to only enable these callbacks if a submit originates in a component inside and ICEfaces portlet in the portlet scenario, and to always enable this in a none-portlet scenario.

Modified submit event and submit error callbacks registration with JSF bridge so that the callbacks are invoked only when ICEfaces submit functions are used.

This is a snippit of my own code:

_keyUp : function(e) {
if ( e.which === 38 )

if ( e.which === 40 )

if ( this._keywordsField.get( "value" ).length >= this.get( "minimumChars" ) ) {
jsf.ajax.request(
Y.Node.getDOMNode( this._keywordsField ),
e,

);
}
else

},

I am making my own jsf.ajax.request call prompted by a keyUp event.

------

sorry for the formatting, i cant seem to find a way to get jira to recognized this snippit as code...

Do you know which event is actually causing the problem?

for your evaluation

---- CLONED FROM http://jira.icefaces.org/browse/ICE-4614 AS THERE IS NO OPTION TO REOPEN ----

Really? The only workaround is to: "Use ICEfaces everywhere."? This is a problem as I have a portal which mixes all kinds of portlets. Some are jsp, some jsf, and some jsf with icefaces. The problem is those that are just plain jsf have all of their ajax requests hijacked by icefaces. This is causing failures here:

function configurationOf(element) {
return detect(parents(element),
function(e)

).configuration;
}

Since the portlet did not have the icefaces jar, it did not inject the .configuration property that this method is looking for, so this function actually returns null and any attempt to make a call against the returned value will fail. Is there a way to tell icefaces to ignore this portlet? Or more to the point could you have icefaces only hijack the functions of portlets that have the icefaces jar in their lib?

A little more investigation shows that this is done when icefaces registers an onEvent handler through a call to jsf.ajax.addOnEvent. Perhaps the handler method could fail gracefully if the configuration is not found that way the request could proceed and jsf ajax could work even with icefaces adding that handler? It seems that icefaces interfering with other non-icefaces content is a major design flaw.