last issue fixed in rev 38315 (MOBI-320)

If you include only one form in the root of the page the following stack trace occurs after causing a form submit after a pane change:

java.lang.IllegalArgumentException: ""
at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:576)
at org.icefaces.mobi.component.contentstack.ContentStackRenderer.encodeScript(ContentStackRenderer.java:152)
at org.icefaces.mobi.component.contentstack.ContentStackRenderer.encodeEnd(ContentStackRenderer.java:132)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:881)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
at org.icefaces.mobi.utils.JSFUtils.renderLayoutChild(JSFUtils.java:241)
at org.icefaces.mobi.component.pagepanel.PagePanelRenderer.encodeEnd(PagePanelRenderer.java:100)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:881)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
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:851)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1779)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:439)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124)
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)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1812)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

rev. 36996

We also have to ensure that a client side selection of a pane should not be reverted by a subsequent form submission. eg:

1. user clicks commandButton that sets the content pane to pane1.
2. user clicks pane2 in the contentStackMenu and is taken to pane2 with a transition.
3. user submits a form on pane2.

After the step 3 the current pane should stay pane2 and the UI should not be reverted to pane1, eventhough the server side binding at that point might still be pane1. In order to make this work sensibly we may need to take the timestamp of client and server side pane changes into account. eg. if the server side binding says pane1, but the timestamp is earlier than the last client side selection, the contentStack should not be updated to pane1. Later client side pane selections should always override the server side binding.

should have explained that the reason that this was not updated was because all the contentPane's are "client", so the state on the client side is not getting updated by the server (all client). This could be what the issue is and I may have misunderstood, so will also look at this to ensure that even if they are all client side panes, any server update should switch panes (but you still won't see transitions as a result as commandButton and server side switch will not necessarily trigger transitions --no guarantee).

see ...mobitest/pagePanel/pagePanelWithContentNavBar.jsf or ....mobitest/pagePanel/pagePanel2WithContentNavBar.jsf
currently they are not getting the correct class for transitions applied, so will fix that and if this markup can be used, should be good enough .