Werner, sorry for the short reply on that email, the "tone" probably sounded bad. There are state saving problems when using MyFaces. Unfortunately it is bad enough to make it completely non-functional as all PPR post backs fail to restore the state from what I have seen. We have no such errors when using Mojarra.
@Matthias or Max: did one of you guys already file a bug on the MyFaces Core for this or do we still need to? To reproduce: 1) Get a working copy of the jsf2_ajax.3 Trinidad Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 2) Run the demo project using Jetty (mvn jetty:run -PjettyConfig) 3) Hit the page: http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml 4) Click on one of the buttons at the top (Full Submit button is fine) This error results: SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /demos/ajaxPPRDemos.xhtmlNo saved view state could be found for the view identifier: /demos/ajaxPPRDemos.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:114) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Form Data sent: itxt1:Change this text2 sf20%3Aitxt2:Change this text2 it1: org.apache.myfaces.trinidad.faces.FORM:j_id933005119_379c87b2 _noJavaScript:false javax.faces.ViewState:!yabr3gltb : javax.faces.behavior.event:action javax.faces.partial.event:click javax.faces.source:axBtn2 javax.faces.partial.ajax:true javax.faces.partial.execute:axBtn2 javax.faces.partial.render:btnTarget Request Headers: Content-Type:application/x-www-form-urlencoded Faces-Request:partial/ajax Origin:http://localhost:8080 Referer:http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml User-Agent:Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 On Tue, Apr 20, 2010 at 9:37 AM, Werner Punz <werner.p...@gmail.com> wrote: > Am 20.04.10 17:00, schrieb Andrew Robinson: >> >> Also, are you using JSF RI? MyFaces is known to be bad with Ajax. > > Ouch that hit me personally, because I and others spent a load of hours to > make > the our javascripts as good as possible as the spec allowed (with the help > of some others). > > Actually if you have run into any errors or problems regarding the Ajax part > (which caused your conclusion), please post them to the jira under our impl > section, so that we can fix it :-), just saying bad with ajax is no help > here :-), we would like to have the best ajax implementation of both > implementations (better than the RI, so any bugreport is welcome). But no > offence taken, back to the topic. > > But back to the original problem, the first link (Go to Trinidad demos home > page.) issue following xhr post: > > > > Tr-PPR-Message true > _noJavaScript false > event autosub > itxt Change this text > j_id1078059021_4041e82d > javax.faces.ViewState !h19u5lcmm > javax.faces.ViewState !h19u5lcmm > javax.faces.partial.ajax true > javax.faces.partial.event click > javax.faces.partial.execu... null > javax.faces.source null > org.apache.myfaces.trinid... j_id1078059021_4041e08f > partial true > selOne 0 > source j_id1078059021_4041e6c3 > > and the response is following: > > > <?xml version="1.0" ?> > <partial-response><changes><update > id="tr_j_id1078059021_4041e08f_Postscript"><![CDATA[<span > id="tr_j_id1078059021_4041e08f_Postscript"><input type="hidden" > name="source"><script > type="text/javascript">TrPage.getInstance()._addResetFields('j_id1078059021_4041e08f',["source"]);</script><script > type="text/javascript">var > j_id1078059021_4041e08f_SF={};</script></span>]]></update><update > id="javax.faces.ViewState"><![CDATA[!h19u5lcmm]]></update><eval><![CDATA[TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');]]></eval></changes></partial-response> > > Not sure what the eval > TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx'); > in this case triggers, it should trigger a go to the homepage. > > > Werner > >
