This is a fuller solution to ICE-8180 / ICE-8223, and uses lessons learned from them, as well as some of the code developed in them, although re-architected.

Extend TagHandler instead of BehaviorHandler, which involves directly implementing code instead of delegating to opaque JSF impl class. Also adds the concept of having nested (f:ajax is child of another tag), and wrapped (f:ajax is the parent of other tags) scenarios. Can more directly setup the created AjaxBehavior instance. And there's a subtle difference of treating a composite component parent as potentially a ClientBehaviorHolder itself. Not sure if that was relevant though.

Investigated Mojarra and MyFaces techniques of having f:ajax work both in a nested, and wrapped scenarios. Found way of interoperating with Mojarra for all nested scenarios, but only some with MyFaces. More work could be done there with proper test cases. Won't fully work with wrapping composite components though, as this is done incompatibly and opaquely in Mojarra and MyFaces. Refer to comments in AjaxBehaviorHandler.applyWrapped for more details.

Moved the listener invocation from AjaxBehavior.broadcast to AjaxBehaviorListenerImpl, and the MethodExpression creation from AjaxBehaviorHandler's MetaRuleset code to AjaxBehaviorHandler.addListenerToAjaxBehavior. New superclass doesn't provide MetaRuleset creation anymore. Now we don't need the MethodRule changes that were introduced in ICE-8180 / ICE-8223.

Added lazy evaluation of ValueExpressions for ace:ajax properties, which had previously been evaluated at construction time to their primitive values. Now state save the attached state for the ValueExpressions.

trunk
Subversion 29525

Instead of the re-architecting, I had investigated an in-between change, of still inheriting from BehaviorHandler, instead of TagHandler; using the MetaRuleset and broadcast, instead of an AjaxBehaviorListener; and not needing the ICE-8260 generator change, while still incorporating lazy evaluation of ValueExpressions. It didn't work though, failing the ICE-8221 test. I've attached the source for that attempt, in case it's ever needed.

Re-open due to regressions.

When navigating to the ace:ajax test page, there is an exception in the server logs. To reproduce:
1. Build / deploy test application (this can be for any component with ajax functionality, for example: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/dialog)
2. Navigate to the Ajax test page

SEVERE: Servlet.service() for servlet Faces Servlet threw exception
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
at org.icefaces.ace.component.ajax.AjaxBehavior.isDisabled(AjaxBehavior.java:142)
at org.icefaces.ace.component.ajax.AjaxBehaviorRenderer.getScript(AjaxBehaviorRenderer.java:69)
at javax.faces.component.behavior.ClientBehaviorBase.getScript(ClientBehaviorBase.java:103)
at org.icefaces.ace.renderkit.CoreRenderer.encodeClientBehaviors(CoreRenderer.java:249)
at org.icefaces.ace.component.tooltip.TooltipRenderer.encodeScript(TooltipRenderer.java:178)
at org.icefaces.ace.component.tooltip.TooltipRenderer.encodeEnd(TooltipRenderer.java:76)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1764)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
at org.icefaces.impl.renderkit.RendererWrapper.encodeChildren(RendererWrapper.java:49)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1757)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:402)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
at java.lang.Thread.run(Thread.java:619)

When literal values were used, instead of EL, for the ace:ajax properties, I wasn't using the API that did EL coercion. This affected disabled and immediate.

trunk
Subversion 29534

When relying on the default event name, instead of an explicit one, the code that adds the AjaxBehavior to the ClientBehaviorHolder was doing nothing given a null event name. Had to resolve the event name from the default first, before adding it.

trunk
Subversion 29535

Possible regression:

I've retested showcase on icefaces3/trunk revision# 29535. The following issue is present:

ace:panel > Listener

• The listener never gets called (or at least, the values do not get updated on the page) when interacting with the panel.

Basically this is the same root issue as ICE-8223, but with the new code base. dateTimeEntry, dialog and panel all use custom event objects that sub-class AjaxBehaviorEvent. When the ace:ajax listener invocation was changed from using MethodRule and broadcast, to using AjaxBehaviorListenerImpl, those custom events needed to be updated. With broadcast invocation, events don't fire themselves, but with the AjaxBehaviorListenerImpl way, they do fire themselves (as is the JSF norm). So the events just need to stop overriding and thwarting the self firing methods inherited from their super-class.

Tested dateTimeEntry, dialog, panel regression tests, and can confirm they all submit to the server, but the listener isn't invoked. Tested against the different special case from ICE-8223, notificationPanel, that does use an AjaxBehaviorEvent, and not a custom sub-class, and found that its listener is getting invoked.

Removed the isAppropriateListener and processListener overrides from CloseEvent, DateSelectEvent, DateTextChangeEvent and ToggleEvent, and retested the components. They all work now.

trunk
Subversion 29555