You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shale.apache.org by "Nick Gomm (JIRA)" <ji...@apache.org> on 2007/06/21 12:34:26 UTC

[jira] Updated: (SHALE-450) Server Side state saving is not saving the sequence generated to the client, leading to errors when always restoring the latest state.

     [ https://issues.apache.org/struts/browse/SHALE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Gomm updated SHALE-450:
----------------------------

    Description: 
org.apache.shale.clay.faces.ClayViewHanlder.renderView is only checking for client side state saving to replace the state saving markers with the serialized state.  If you are using server side state saving then nothing is written.  

I have built a test version which always replaces the state saving markers with the state, as on mine it ends up calling org.apache.myfaces.renderkit.html.HtmlResponseStateManager.writeState which takes into account whether you are using server or client side state saving.  If server side is in use then the sequence and viewid are written so this can be restored from the map of states saved on the session.  

Problems were occuring if you spawed a new window and then went back to the original window.  When you actioned something on the original window, the latest state was restored (which was the new window) and thus errors could occur.  Also, using the back button totally messed up the state.  By saving the sequence to the page, when resubmitted the appropriate state can be looked up ( assuming it is in the last 20).


  was:
org.apache.shale.clay.faces.CalyViewHanlder.renderView is only checking for client side state saving to replace the state saving markers with the serialized state.  If you are using server side state saving then nothing is written.  

I have built a test version which always replaces the state saving markers with the state, as on mine it ends up calling org.apache.myfaces.renderkit.html.HtmlResponseStateManager.writeState which takes into account whether you are using server or client side state saving.  If server side is in use then the sequence and viewid are written so this can be restored from the map of states saved on the session.  

Problems were occuring if you spawed a new window and then went back to the original window.  When you actioned something on the original window, the latest state was restored (which was the new window) and thus errors could occur.  Also, using the back button totally messed up the state.  By saving the sequence to the page, when resubmitted the appropriate state can be looked up ( assuming it is in the last 20).



> Server Side state saving is not saving the sequence generated to the client, leading to errors when always restoring the latest state.
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SHALE-450
>                 URL: https://issues.apache.org/struts/browse/SHALE-450
>             Project: Shale
>          Issue Type: Bug
>          Components: Clay
>    Affects Versions: 1.0.4, 1.1.0-SNAPSHOT
>         Environment: Tomcat 5 on Windows XP
>            Reporter: Nick Gomm
>
> org.apache.shale.clay.faces.ClayViewHanlder.renderView is only checking for client side state saving to replace the state saving markers with the serialized state.  If you are using server side state saving then nothing is written.  
> I have built a test version which always replaces the state saving markers with the state, as on mine it ends up calling org.apache.myfaces.renderkit.html.HtmlResponseStateManager.writeState which takes into account whether you are using server or client side state saving.  If server side is in use then the sequence and viewid are written so this can be restored from the map of states saved on the session.  
> Problems were occuring if you spawed a new window and then went back to the original window.  When you actioned something on the original window, the latest state was restored (which was the new window) and thus errors could occur.  Also, using the back button totally messed up the state.  By saving the sequence to the page, when resubmitted the appropriate state can be looked up ( assuming it is in the last 20).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.