From: Giampaolo Tomassoni [mailto:[EMAIL PROTECTED] > > ...omissis... > > > > Is there any way to circumvent this problem? Is the way myfaces > > > handles GET with parameters a by-design behaviour? Is so, > which is the > > > purpouse? Is there a way (maybe by mean of some init param) to > > > instruct facelets to handle GETs always with a RESTORE_VIEW and > > > RENDER_RESPONSE cycle, and not as a form submission? > > > > > > Our solution is a custom PhaseListener that checks the method property > > of the request, and discards any component tree that may have been > > retrieved during RESTORE_VIEW (thus forcing a jump to RENDER_RESPONSE). > > > > public void afterPhase(PhaseEvent event) { > > if (event.getPhaseId().equals(PhaseId.RESTORE_VIEW)) { > > // Never do a postback on GET request. > > // Ideally this check would be done in > > // before-restore-view, but JSF provides no way for > > // code to skip the restore-view processing. We > > // therefore need to let the normal restore-view > > // take its course, then forcibly override the results > > // here :-(. > > FacesContext fc = event.getFacesContext(); > > ExternalContext ec = fc.getExternalContext(); > > HttpServletRequest hreq = (HttpServletRequest) > > ec.getRequest(); > > if (hreq.getMethod().equals("GET")) { > > // discard UIViewRoot created during restoreView > > // and use a new one > > UIViewRoot viewRoot = fc.getViewRoot(); > > String viewId = viewRoot.getViewId(); > > UIViewRoot newView = > > fc.getApplication(). > > getViewHandler().createView(fc, viewId); > > newView.setViewId(viewId); > > fc.setViewRoot(newView); > > fc.renderResponse(); > > } > > } > > } > > > > Note that this code checks PhaseId==RESTORE_VIEW because our version of > > this listener actually does several things, so is active for > all phases. > > If your version only returns RESTORE_VIEW as its active phase then this > > check is not needed. > > Thank you very much for sharing your code with me: I didn't even > know where starting "patch" jsf to fix my problem. > > I guess that jsf-1.2 attempts fixing the "is it a postback?" > problem, since it defines a isPostback() getter in the > ResponseStateManager class. I suspect this is done exactly to > allow the renderkit to more precisely discriminate > "show-the-page" requests from true postback ones. > > Even not implementing the full jsf-1.2 specs, I guess that > myfaces should apply more effort in discriminating the two cases. > Please note also that method > org.apache.myfaces.shared_impl.renderkit.html.HtmlFormRendererBase > .encodeBegin in myfaces-1.1.4 says: > > <snip> > writer.startElement(HTML.FORM_ELEM, htmlForm); > writer.writeAttribute(HTML.ID_ATTR, clientId, null); > writer.writeAttribute(HTML.NAME_ATTR, clientId, null); > writer.writeAttribute(HTML.METHOD_ATTR, "post", null); > writer.writeURIAttribute(HTML.ACTION_ATTR, > > facesContext.getExternalContext().encodeActionURL(actionURL), > null); > </snip> > > Which means that every and each <h:form> in myfaces-1.1.4 is to > be handled through a POST request. This may mean that every and > each GET request may be seen as not being a postback, but it > seems that myfaces-1.1.4 does not enforce this. Please see the > following excerpt from the > org.apache.myfaces.lifecycle.LifecycleImpl.execute method: > > <snip> > if > (facesContext.getExternalContext().getRequestParameterMap().isEmpty()) > { > //no POST or query parameters --> set render response flag > facesContext.renderResponse(); > } > </snip> > > See? A GET is a postback if and only if it carries parameters > (which is compatible with my experience about refreshing pages > with no parameters). Even wider, a postback is as such > irregardless of the carring method (POST or GET), which is > compatible with what you told me about a JSF postback being > carried by a GET, but which also seems not compatible with the > specific myfaces-1.1.4 impl. of an html form. > > So, would it be possible to assert that, in the myfaces > implementation, postbacks are handled only by POST (maybe > non-empty) requests? What is supposed to be the payload of a > postback GET when all the forms use POST methods instead? I don't > have such a deep knowledge of the JSF framework to reply to this.
I recently placed a Jira issue about this matter: http://issues.apache.org/jira/browse/MYFACES-1523 . We will see. Cheers, Giampaolo > > > > Cheers, > > > > Simon > > Thanks Simon. I really appreciate your help. > > Cheers dear, :) > > Giampaolo >
