SEVERE: java.lang.IndexOutOfBoundsException: Index: 2, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.remove(ArrayList.java:387)
at org.icefaces.ace.component.messages.MessagesRenderer.encodeEnd(MessagesRenderer.java:94)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:877)
at org.icefaces.ace.renderkit.CoreRenderer.renderChild(CoreRenderer.java:80)
at org.icefaces.ace.renderkit.CoreRenderer.renderChildren(CoreRenderer.java:64)
at org.icefaces.ace.component.panel.PanelRenderer.encodeContent(PanelRenderer.java:238)
at org.icefaces.ace.component.panel.PanelRenderer.encodeMarkup(PanelRenderer.java:135)
at org.icefaces.ace.component.panel.PanelRenderer.encodeEnd(PanelRenderer.java:73)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:877)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1826)
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:847)
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:847)
at org.icefaces.ace.renderkit.CoreRenderer.renderChild(CoreRenderer.java:76)
at org.icefaces.ace.renderkit.CoreRenderer.renderChildren(CoreRenderer.java:64)
at org.icefaces.ace.component.panel.PanelRenderer.encodeContent(PanelRenderer.java:238)
at org.icefaces.ace.component.panel.PanelRenderer.encodeMarkup(PanelRenderer.java:135)
at org.icefaces.ace.component.panel.PanelRenderer.encodeEnd(PanelRenderer.java:73)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:877)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:312)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
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:847)
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:847)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1819)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822)
at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPartialViewContext.java:150)
at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:973)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1819)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:421)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
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)

When the first lifecycle created two FacesMessages A and B, and then the next lifecycle created the exact same two FacesMessages A, B, then the new/changed detection code was removing the FacesMessages from a list in the wrong sequence, so the indexes would shift and then be trying to access past the end of the list. Reversing the sequence of removal fixed it.

We should add regression tests that deal with the various scenarios of adding, removing and changing FacesMessages.

icefaces3 trunk
Subversion 37480

In showcase ace:message(s) demo, you can generate two different faces messages for a component: empty input or input same as input field label. (Read the demo description.)

New message is when previously there was no message (either initially or right after valid input); changed message is when previously there was another message. (E.g. first empty input then type field label as input.)

Effects should be different for new and changed messages. No effect any other case.

Or you can write your own test app. Follow the example code in the backing bean to generate whatever and however many faces messages you want.

Logic to distinguish between "init" and "change" done according to Mark's suggestion. Two-pass process. Required major rewrites. Summary:

Given an old list and a new list of messages for a component client id (or null for global messages): filter and render out common message texts; for all remaining message texts that are not in both lists, compare the lists by position (not message text). Any new position < size of old list are changed messages; any new position >= size of old list are new messages.

M: C:\svn\ossrepo\icefaces3\trunk\icefaces\samples\showcase\showcase\src\main\webapp\resources\examples\ace\message\message.xhtml#37033
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\messages\Messages.java#37033
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\messages\MessagesRenderer.java#37033

Effects added for <ace:messages/>. However, the main problem still remains, after much (often sidetracked) discussion:

Given:

• A prev. set of msgs. for a client id
• A curr. msg. for the same client id not in prev. set

How can we distinguish between an "init" (non-existent prev. msg.) and a "change" (changed prev. msg.)? Just try filling in the conditions in screenshot-03.

Currently invalid effect and duration values are silently defaulted to default values.
Requirement from Mark: add logging when in ProjectStage.Development.

Done. (I actually don't like unnecessary logging cluttering up a program.)

M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\message\MessageRenderer.java#35594

No need for such brute force and complexity. I have tracked down the real cause for the message disappearing. See screenshot-01. Furthermore, "... callback function ... this is not necessary when you simply want to perform multiple effects in sequence. By default, jQuery's animations are queued." — JavaScript: The Definitive Guide, 6th ed., p. 552. It would just be simpler to chain the show(), if needed.

"fade" and "size" effects have an opposite problem: the message would show but there is no discernible animation, not even with a long duration. "fade" requires pre-chaining a hide() first; "size" requires setting some internal options specific to its effect.

TLD doc and showcase demo updated.

M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\build.xml#35375
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\message\Message.java#35375
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\samples\showcase\showcase\src\main\webapp\resources\examples\ace\message\message.xhtml#35375
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\samples\showcase\showcase\src\main\java\org\icefaces\samples\showcase\example\ace\message\MessageBean.java#35375
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\message\MessageMeta.java#35375
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\message\MessageRenderer.java#35375
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\resources\icefaces.ace\messages\messages.css#35375
A: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\resources\icefaces.ace\messages\messages.js#35375
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\samples\showcase\showcase\src\main\resources\org\icefaces\samples\showcase\view\resources\messages.properties#35375

[10:51:02 AM] Ken Fyten: Need to examine the final state CSS for the hidden messages to see what CSS is causing them to disappear after the effect.
[10:51:28 AM] Ken Fyten: Then, possible to force it to restore the offending CSS state to the default after the effect completes in the jQuery effect call.
[10:53:50 AM] Nils Lundquist: http://uncorkedstudios.com/2011/12/12/how-to-fix-the-ie7-and-inline-block-css-bug/ (getting inline-block working on IE7 needs a IE-specific CSS hack (for elements that aren't inline by default))

All requirements from last meeting done:

• All special positioning and spacing CSS removed. HTML and CSS changed to be almost exactly like in dataTable config. panel example, except its use of positioning to stack the triangle icons. Use of inline-block suppresses ThemeRoller's icon block-display, thus simplifying other CSS. (I was reluctant to use inline-block because I had seen too many cross-browser problems before.)

• Previous message stored in component on server-side. Compare done on server-side. Event determination done on server-side.

• Effect done for "init event". (Message text change from nothing to something.)

• Effect done for "change event". (Message text change from something to something else.)

• No script output in all other cases, including change in icon, severity, effect, effect duration, message text from something to nothing, ......

However, now there is a new animation problem:

Somehow, for some effects, the message just disappears after the animation, as if it had turned into a hide effect. All effects are done by the same show effect animation method call, just one line of jQuery JS. Request-Response is OK; DOM update is OK; JS execution is OK. Strange. And why didn't it happen before the CSS changes? See video.

Next up, ace:messages. Immediate concern:

• A faces message has no id
• Set of messages returned in no particular order
• Set of messages returned could differ each time

How do we do the compare-with-previous for individual messages?

Responses

• For the ace:message styling issues when animating, let's try using an inline-block styling approach.

• The desired behaviour is for the server-side component to determine if the message content has changed (by comparing the current message contents to the previous render - if any). If the message content has changed, then the animation should be fired on the client.

• We do not want to support animation for removing the message, that is out of scope due to complexities it entails around holding up a dom update for an animation to complete. Plus, animating the removal of a message is less informational to the user than animating the initial display or update of a message.

• If the effect configuration changes, there is no need to immediately fire the animation if the message contents haven't changed, but the correct effect config. should be used the next time the message is animated due to a change.

First attempts working. But some effects just mangle the icon/message while in animation (see video), probably due to the tricky spacing/positioning CSS underlying the icon/message.

Other issues to work out:

• How to determine if it is an initial display on server side? (From nothing to something.)
• How to detect content change on server side? (From something to something else.)
• What about change from something to nothing?
• What about change in severity? icon? (Fatal and Error: different severity but same icon.)
• Do these on client side? No such event as content change event?
• What about just change in effect? effectDuration?
• ......