Not sure on my side, I'm really not into AJAX. I followed the discussions, but really not deeply enough to get that kind of detail. :(
~ Simon On Wed, May 6, 2009 at 1:02 PM, Werner Punz <[email protected]> wrote: > Ok Since Ganesh pointed it out, this is even better. > We probably wont need a parser at all. > The section describing javax.faces.ViewRoot as > ppr update id basically omits the entire parsing stage. > They way I interpete it for now is that we can > serve the innerHTML of the html tag and have > a simple innerHTML replacement (with optional > script triggers, for embedded scripts, which also > can be covered by a following eval part) > > So this means the work is entirely offloaded > to the responseWriter. > I have committed my parser, but I am more than glad > to rip it out again and drop it into oblivion > (I am always a big fan of throwing away code to reduce > the codesize) > > > Another issue: > The spec seems to have changed regarding the viewState handling on the > client side in the pr > pr case last minute: It seems that it now is just changing the viewState of > the submitting form of the ppr request. Is this correct or an errata in the > latest spec? > > If yes do we still have to add missing viewState elements if the form does > not have one, and is the entire, change all viewstate elements part entirely > dropped? > > The last jira entries did not show any big changes except for > s/identifier/name which we requested? > > Can anyone of the EG guys comment on this? > > > Werner > > > > Werner Punz schrieb: > >> Looks ok to me, the parsing is not omitted but instead >> the option to render the head and body without parsing is added. >> Either way, I have the parser in place now and will commit it tomorrow. >> So we have the harder part in place and working and it is fast enoguh. >> >> 80.000 characters are handled within 1.5 seconds which is fast enough! >> I will commit it tomorrow since I am currently at a customer... >> >> >> Werner >> >> >> >> Roger Kitain schrieb: >> >>> Ganesh wrote: >>> >>>> >>>> [2] The jsdoc on javax.faces.response defines a behaviour for update >>>> elements with the id javax.faces.ViewRoot. By testing with the RI I >>>> found out that this behaviour is triggered if an AJAX requests triggers >>>> a naviagtion rule that leads to a different page. It's a cool thing to >>>> have a well defined behaviour in this case, but the spec doesn't define >>>> it. It's just what Mojarra does. Can you please add a paragraph that >>>> defines the circumstances under which the server has to respond with >>>> javax.faces.ViewRoot? >>>> >>> This is now fixed - see: >>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=554 >>> >>>> >>>> [3] In the javax.faces.ViewRoot case Mojarra returns a complete document >>>> with DOCTYPE, html, head and body. It is left to the Javascript >>>> implementation to separate these and replace the head and body sections. >>>> This is a tedious task involving a parser that deals with html comments, >>>> Javascript comments and CDATA sections within the HTML page. The >>>> Javascript code Mojarra brings for this is unsufficient and fails for >>>> many cases. We are currently working on a parser. Things would be a lot >>>> easier if the spec would force the server to return separate CDATA >>>> blocks within javax.faces.ViewRoot for the head and the body tag and to >>>> omit the html tag and the DOCROOT. This can't be too hard to implement, >>>> because head and body are rendered by h:head and h:body. Can you please >>>> define the format for javax.faces.ViewRoot to contain 2 CDATA sections, 1 >>>> optional with the head tag and 1 required with the body tag? >>>> >>> Fixed- See: >>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=557 >>> >>>> >>>> Best Regards, >>>> Ganesh Jung >>>> >>>> >>> >>> >> >> >
