[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1293) Page parameters not working

[Chris Rudd (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBSEAM-1293?page=comments#action_12361593 ] 
            
Chris Rudd commented on JBSEAM-1293:
------------------------------------

I checked out MyFaces 1.1.5 and its a problem as well. (the server state loading process is almost identical)

So the issue is, 

A) should a GET request ever go through the whole lifecycle or should it just do a render.
  I belive it should just do a render, as that is always how a GET is handled when doing client side state saving.

B) The current logic in Seam relies on renderResponse being called to indicate that the request should skip to the render phase immediatly folowing the RESTORE_VIEW phase. Since there are issues with this (as seen when MyFaces), is there a better more approproate way to handle this? The 1.2.0-Patch1 implemented the logic differently and I belive it was not affected by the MyFaces issue (although it looks like the patch1 code was significantly more complex).

Currently I have a workaround:
  I install a Phase listener looking for the AfterPhase - RESTORE_VIEW event. I determing if the request was a GET, and if it was I call facesContext.renderResponse. This way when the Seam PhaseListener processes the event, it follows the correct code branch.

Im assuming that the intention for Page parameters is that they are only ever pulled from the request parameters if this is the initiating GET request, after that they are always pulled from the ViewRoot's attributes. Thus making them essentially PageContext scoped values that can be initialy set from the originating GET's parameters.


> Page parameters not working
> ---------------------------
>
>                 Key: JBSEAM-1293
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-1293
>             Project: JBoss Seam
>          Issue Type: Bug
>    Affects Versions: 1.2.1.GA
>            Reporter: Chris Rudd
>
> Im attempting to use the Page parameter feature detailed in section 5.1.1.1 of the documentation. 
> <pages>
>      <page view-id="/edit.xhtml">
>          <param name="id" value="#{editor.id}"/>
>      </page>
> </pages>
> based on my understanding of the functiuonality if i go the url /edit.xhtml?id=foobar then editor.id should be set to 'foobar'.
> This is not occuring. After tracing the code it seems like this is where the magic should happen:
> AbstractSeamPhaseListener.java : 70
>     //apply page parameters to the model
>       if ( facesContext.getRenderResponse() )
>       {
>          Pages.instance().applyRequestParameterValues(facesContext);
>       }
>       else
>       {
>          Pages.instance().applyViewRootValues(facesContext);
>       }
> Im using myfaces 1.1.4 with server side view state. What appears to be happening is that myfaces will restore the saved view state (im not sure it should be, as its a GET request). When this happends facesContext.renderResponse is never called.
> Thus when it gets to the above code, the page parameters are restored from the wrong location.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira