I've noticed a regression jira about setEventPhase. We should probably fix ICE-8233 before moving it to core.

Also, I noticed that with ICE-4983 a fix for setEventPhase was made to icefaces trunk but not to icefaces3 trunk. We should probably incorporate that fix into icefaces3.

Component is moved into core, but ICE-4983 has not been applied.
No test case exists for the component in the new namespace.

The fix in ICE-4983 has not been applied since it is specific to a compat component. The showcase demo is now using the icecore component.

ICE-4983 touches on the issue that any UIData / UIRepeat container will wrap a FacesEvent, that bubbles up the queueEvent chain from within it, inside a new custom FacesEvent that includes the row information for the container. Unfortunately, with UIData and UIRepeat, those custom events are not public classes, and so there is no means to inspect the event that they wrap. So when setEventPhase tries to filter events by their type, for which it will operate on, the wrapper type is what it will find, and not the underlying true event type. ICE-4983 allowed for deep inspecting a single compat wrapper event, but didn't account for ACE containers nor the stock containers. I think it's best that we simply don't try to provide this very limited deep inspection, and instead document that the events property of setEventPhase can only be specific of the event type when directly wrapping a component, and needs to be generic ("javax.faces.event.FacesEvent" / "FacesEvent") when wrapping a container that wraps events.

Wiki documentation added:

http://wiki.icesoft.org/display/ICE/setEventPhase

Added some documentation for the limitations found in ICE-4983, where events are wrapped by UIData and UIRepeat containers, so the events property won't match on their original class name.

icefaces3 trunk
Subversion 29854