In the RichFaces library, we have a 2 strategies ( they are different for the client and server side state savings ). First one, for a server-side state, we overwrote StateManager to keep a 'stateId' value a same during AJAX requests. Therefore, that value is not updated by AJAX requests. Otherwise server-side cache can be quickly overloaded what breaks browser back-button support. In the case of client-side state saving, a new state sent in the ajax response and updated by the client-side script everywhere on page. The portlet is a special case. Because portletbridge have to keep request state on the server for 'render' requests support, client-side state saving does not make sense. Because we do not update VIEW_STATE field value in this case, we have no namespace problems. Really, the client-side state saving is also supported but with a special hack: our bridge implementation renders <div> element with ID created from the portlet namespace. Client-side library updates hidden fields in the that element only. As I already wrote, the most common way to resolve namespace problems is special ResponseStateManager which should write namespace-prefixed view state hidden field for portlets. It is not necessary to include that class in the JSF spec, it may be included in the portlet bridge only. That class also solves the other portletbridge problem: parsing view state field in the StateManager instance, what looks like a hack... Out of topic: Michael, is it ok for me to take part in the portlet bridge meeting on 03/04 ? michael freedman wrote: > By the way, how are JSF Ajax solutions dealing with the multi-form > case in JSF 1.2? Is there a consistent strategy? Is it often > overlooked? For all on the list, for whatever environment you know > the strategy for, please post. I will collate into a matrix, afterwards. > -Mike- > > Roger Kitain wrote: >> For Ajax, here is what we do w.r.t javax.faces.viewState: >> >> If an update element is found in the response with the identifier >> javax.faces.ViewState: >> >> <update id="javax.faces.ViewState"> >> <![CDATA[...]]> >> </update> >> >> Include this state in the document as follows: >> >> * Extract this <update> element's CDATA contents from the response. >> * If the document contains an element with the identifier >> javax.faces.ViewState replace its contents with the CDATA contents. >> * For each <form> element in the document: >> o If the <form> element contains an <input> element with the >> identifier javax.faces.ViewState, replace the <input> element >> contents with the <update> element's CDATA contents. >> o If the <form> element does not contain an element with the >> identifier javax.faces.ViewState, create an <input> element of the >> type hidden, with the identifier javax.faces.ViewState, set its >> contents to the <update> element's CDATA contents, and add the >> <input> element as a child to the <form> element. >> >> -roger >> >> michael freedman wrote: >>> Alexandr is also right, there maybe Ajax related problems as well at >>> least in the portlet case. Doesn't the PPR processing need to >>> update the ViewState after a partial request? Do we expect (by >>> spec) all impls to manage the viewstate in a javascript variable and >>> have the various hidden fields pull this value on full page >>> submits? Or might impls try and push the updated ViewState into the >>> hidden field? If the later won't they have problems in a multi-form >>> page? If the former, what can we do to account for the portlet >>> situation where I have multiple portlets on a page each with >>> distinct ViewState? I.e. if the portlet renders a JSF view its >>> ViewState is distinct from another portlet (rendering a JSF view) >>> incorporated into the page. >>> -Mike- >>> >>> Pete Muir wrote: >>>> At least in JSF1.2 Mike is correct, the hidden form field written >>>> out to set the viewstate parameter has the same id for each form, >>>> which means the HTML is not well formed and would not pass an HTML >>>> validator. >>>> >>>> I remember coming across this before and raising it with someone - >>>> perhaps Ryan or Ed? >>>> >>>> On 26 Feb 2009, at 21:19, Alexandr Smirnov wrote: >>>> >>>>> Faces allows as many form on page as you wish. The fields with >>>>> state do >>>>> not mixeed as they as are unique per form. This is not a problem for >>>>> Portlet applications, because only one hidden field submitted by >>>>> form. >>>>> But that could be problem for an AJAX case, there client-side >>>>> script >>>>> have to found appropriate state field to include in >>>>> HttpServletRequest. >>>>> >>>>> michael freedman wrote: >>>>>> From the looks of things in JSF 1.2 (and I imagine this hasn't >>>>>> changed >>>>>> in 2.0), JSF's hidden field holding the view state parameter is >>>>>> written using a static id/name. I.e. the id of the field isn't >>>>>> namespaced by its containers. Though not a common case, Faces does >>>>>> allow multiple (separate) form tags in a page, right? In that >>>>>> situation aren't we violating strict HTML rules requiring id >>>>>> uniqueness? Why does the id need to be static? Can't we make this >>>>>> unique? >>>>>> -Mike- >>>> >>>> -- >>>> Pete Muir >>>> http://www.seamframework.org >>>> http://in.relation.to/Bloggers/Pete