Hello I am asking this because this because I user ran into this issue by using a dom modifying javascript widget and tried to press it through jsf.ajax.request. (aka a typical dialog widget) The issue is that there is a usecase where you try to execute a ppr within one form and then try to render another form. aka: <h:form id="form1"> ... jsf.ajax.request(this, event, {execute:"form1 form2", render:"form2"}); </h:form> <h:form id="form2"> </form2> The main issue here is that after the request a javax.faces.ViewState element is issued in the ppr cycle. Now the spec says: If an update element is found in the response with the identifier javax.faces.ViewState: <update id="javax.faces.ViewState"> <![CDATA[...]]> </update> locate and update the submitting form's javax.faces.ViewState value with the CDATA contents from the response. Now this works coherently with a single form usecase because the viewstate is issued on the submitting element. The main problem is, both implementations in this special case have another behavior. if the form2 is rendered there is no viewstate element in the udate id="form2" but after that the viewState element is issued, now however myfaces swallows it entirely for form2 because of this spec entry, mojarra updates it only if render:"form2" but if for instance <h:panelGroup id="outerFormGroup"> <h:form id="form2"> </form2> </h:panelGroup> and render:"outerFormGroup" then it is swallowed as well. I assume now following, since the viewState is viewRoot related, should´t we simply update all form elements over the entire page with the new viewState content and simply add this field for form elements where the viewState control is not present? The other solution would be to update all forms where an execute and rendere happend or at least a rendere happend inside (or as parent node of the form) Werner

Hi I filed a bug report under https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=790 But I would need further clarification regarding this issue, so that I can move forward with a fix. Since a fix obviously would not break anything (or unlikely at this stage), I´d rather fix it in the 2.0.1-SNAPSHOT codebase for MyFaces instead of having to wait for a fix on the spec side. But the fix behavior must be inline with the fixed functionality on the spec side in this area, so that I do not program behavior in, which we cannot expect, once this is fixed on spec level (and Mojarra also has to fix this obviously) Have in mind, this is a usecase, which can happen very often, especially in a szenario, where javascript dialogs are used which have to rely on position absolute, directly under the document element (due to IE6 having personal problems with position:fixed) so a typical multi window szenario, where there are lots of embedded frames in dialogs and the dialogs can be pushed through the ppr cycle... Werner On Wed, May 5, 2010 at 3:08 PM, Martin Marinschek <mmarinschek(a)apache.org <mailto:mmarinschek@apache.org>> wrote: Hi Werner, I agree with you - a new view-state should lead to an update of this state in all forms - not only the submitting one. The view-state covers the state for the full _view_ and not the one of one _form_ - everything needs to be updated - or submits from other forms will not be possible anymore! best regards, Martin On 5/5/10, Werner Punz <werner.punz(a)gmail.com <mailto:werner.punz@gmail.com>> wrote: > Hello I am asking this because this because I user ran into this issue by > using a dom modifying javascript widget and tried to press it through > jsf.ajax.request. > (aka a typical dialog widget) > > > The issue is that there is a usecase where you try to execute a ppr within > one form > and then try to render another form. > > aka: > > <h:form id="form1"> > > ... jsf.ajax.request(this, event, {execute:"form1 form2", render:"form2"}); > </h:form> > > > <h:form id="form2"> > </form2> > > The main issue here is that after the request a javax.faces.ViewState > element is issued in the ppr cycle. Now the spec says: > > If an update element is found in the response with the identifier > javax.faces.ViewState: > > <update id="javax.faces.ViewState"> > <![CDATA[...]]> > </update> > > locate and update the submitting form's javax.faces.ViewState value with the > CDATA contents from the response. > > Now this works coherently with a single form usecase because the viewstate > is issued on the submitting element. > The main problem is, both implementations in this special case have another > behavior. > > if the form2 is rendered there is no viewstate element in the udate > id="form2" but after that the viewState element is issued, > now however myfaces swallows it entirely for form2 because of this spec > entry, mojarra updates it only if render:"form2" > but if for instance > <h:panelGroup id="outerFormGroup"> > <h:form id="form2"> > </form2> > </h:panelGroup> > > and render:"outerFormGroup" then it is swallowed as well. > > I assume now following, since the viewState is viewRoot related, should´t we > simply update all form elements over the entire page with the new viewState > content and simply add this field for form elements where the viewState > control is not present? > The other solution would be to update all forms where an execute and rendere > happend or at least a rendere happend inside (or as parent node of the form) > > Werner > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces

On 5/6/10, Alexander Smirnov <asmirnov(a)exadel.com&gt; wrote: > Let me point out that Mojarra already takes care for state in AJAX > requests in the server-side saving. In the case of partial request, > ServerSideStateHelper ( see line 196 ) reuses view state and doesn't > change content of the javax.faces.ViewState parameter, so any request > from page should restore proper state because it has the same id as it > was rendered in AJAX request. > Therefore, that bug applicable for client-side state only, but updating > state parameter for ALL forms on the page could cause problem for portal > environment there each portlet keeps its own state that should not be > updated by requests from others... Interesting problem. So we are rendering multiple forms, and in one case, the forms belong to one application, and in another case, they are from different applications. How can we find out which forms belong to our application? Portal environments will namespace their content, but there is no way for us to find out - right? Would we need to keep track of our forms during rendering? best regards, Martin

Hi Neil, On 5/11/10, Neil Griffin <neil.griffin(a)portletfaces.org&gt; wrote: > Since UIViewRoot does not implement NamingContainer, the JSR 301/329 specs > defines the PortletNamingContainerUIViewRoot [1] which, as its name > indicates, does indeed implement NamingContainer. This is what causes a nice > namespaced ID for all components in the rendered view. The code for this > typically looks something like this: > > public class PortletNamingContainerUIViewRoot extends UIViewRoot implements > NamingContainer, Serializable { > > private static final long serialVersionUID = 6744332823172081041L; > private String namespace; > > @Override > public String getContainerClientId(FacesContext facesContext) { > > if (namespace == null) { > ExternalContext externalContext = facesContext.getExternalContext(); > namespace = externalContext.encodeNamespace(""); > } > > return namespace; > } yes, ok, I knew that. I just don't see how to exploit it, cause the hidden input with id javax.faces.ViewId will _not_ be namespaced. We could determine the namespace and only update the javax.faces.ViewId-elements within forms where the id starts with our namespace? best regards, Martin

Actually I can only talk from the javascript side here. The main issue is that a PPR response does not include a ViewState element, instead the viewState is delivered by the separate viewState xml element. Here is how I bypassed the problem for now for MyFaces, I simply check all elements which are processed (issuer, and updated ones) for embedded forms, after the entire updating is done, and check if the viewstate is set, if not we have to attach the viewstate. The limitation of this approach however is that if a user explicitely issues a cross portlet render directive, there is no way this will work, but however if that is issued the entire lifecycle fails, because it simply is not part of the viewRoot which is processed. So this is a non issue for me. So far this approach works really well, and I am finally able to do stuff like this: http://pastebin.com/TmFGtQyv This is more or less the usecase the user had who pointed me towards this. Not sure if this approach is valid within the spec (the TCK probably will tell), but it is a valid usecase which has to be covered. In my opinion the spec here is at fault, and to my testing Mojarra also has a similar bypass code but it only works on direct form elements being rendered, instead of checking for embedded forms also. Werner On Tue, May 11, 2010 at 11:18 PM, Martin Marinschek <mmarinschek(a)apache.org <mailto:mmarinschek@apache.org>> wrote: On 5/6/10, Alexander Smirnov <asmirnov(a)exadel.com <mailto:asmirnov@exadel.com>> wrote: > Let me point out that Mojarra already takes care for state in AJAX > requests in the server-side saving. In the case of partial request, > ServerSideStateHelper ( see line 196 ) reuses view state and doesn't > change content of the javax.faces.ViewState parameter, so any request > from page should restore proper state because it has the same id as it > was rendered in AJAX request. > Therefore, that bug applicable for client-side state only, but updating > state parameter for ALL forms on the page could cause problem for portal > environment there each portlet keeps its own state that should not be > updated by requests from others... Interesting problem. So we are rendering multiple forms, and in one case, the forms belong to one application, and in another case, they are from different applications. How can we find out which forms belong to our application? Portal environments will namespace their content, but there is no way for us to find out - right? Would we need to keep track of our forms during rendering? best regards, Martin