You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Howard Abrams (JIRA)" <de...@myfaces.apache.org> on 2006/01/14 01:47:20 UTC

[jira] Created: (MYFACES-1026) StateManager.restoreView has bad side effects

StateManager.restoreView has bad side effects
---------------------------------------------

         Key: MYFACES-1026
         URL: http://issues.apache.org/jira/browse/MYFACES-1026
     Project: MyFaces
        Type: Bug
  Components: Implementation  
    Versions: Nightly, 1.1.1    
    Reporter: Howard Abrams


Calling StateManager.restoreView has the side effect of messing up the stored state.

In 1.1.1, calling this method would remove the state from the session, and therefore it would be lost forever if the lifecycle didn't re-render causing the state to be re-stored.

In 1.1.2, multiple states are now stored, but calling this method causes the index number of the current state to be incremented even though a new state may never be stored.

While this bug isn't seen in normal use, it pops up quite quickly when attempting more complicated/different AJAX-style lifecycles.

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


[jira] Commented: (MYFACES-1026) StateManager.restoreView has bad side effects

Posted by "Howard Abrams (JIRA)" <de...@myfaces.apache.org>.
    [ http://issues.apache.org/jira/browse/MYFACES-1026?page=comments#action_12362748 ] 

Howard Abrams commented on MYFACES-1026:
----------------------------------------

If I were changing state I would see your point, but in operations that are non-state-changing it is inefficient to have store the state again. I should also point out that AFAIK the RI doesn't have this side effect, so at the very least MyFaces should allow for compatible phase-Listeners/lifecycles.

In addition to the fact that it is already there and working, is there a strong argument to increment the state index when reading state instead of when writing it?


> StateManager.restoreView has bad side effects
> ---------------------------------------------
>
>          Key: MYFACES-1026
>          URL: http://issues.apache.org/jira/browse/MYFACES-1026
>      Project: MyFaces
>         Type: Bug
>   Components: Implementation
>     Versions: 1.1.1, Nightly
>     Reporter: Howard Abrams

>
> Calling StateManager.restoreView has the side effect of messing up the stored state.
> In 1.1.1, calling this method would remove the state from the session, and therefore it would be lost forever if the lifecycle didn't re-render causing the state to be re-stored.
> In 1.1.2, multiple states are now stored, but calling this method causes the index number of the current state to be incremented even though a new state may never be stored.
> While this bug isn't seen in normal use, it pops up quite quickly when attempting more complicated/different AJAX-style lifecycles.

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


[jira] Commented: (MYFACES-1026) StateManager.restoreView has bad side effects

Posted by "Mathias Broekelmann (JIRA)" <de...@myfaces.apache.org>.
    [ http://issues.apache.org/jira/browse/MYFACES-1026?page=comments#action_12365258 ] 

Mathias Broekelmann commented on MYFACES-1026:
----------------------------------------------

The state index is incremented on reading because multiple requests on the same time for the same session are possible. 
Does anyone know a better solution which still supports the multiple request case?

> StateManager.restoreView has bad side effects
> ---------------------------------------------
>
>          Key: MYFACES-1026
>          URL: http://issues.apache.org/jira/browse/MYFACES-1026
>      Project: MyFaces
>         Type: Bug
>   Components: Implementation
>     Versions: Nightly, 1.1.1
>     Reporter: Howard Abrams
>     Assignee: Mathias Broekelmann

>
> Calling StateManager.restoreView has the side effect of messing up the stored state.
> In 1.1.1, calling this method would remove the state from the session, and therefore it would be lost forever if the lifecycle didn't re-render causing the state to be re-stored.
> In 1.1.2, multiple states are now stored, but calling this method causes the index number of the current state to be incremented even though a new state may never be stored.
> While this bug isn't seen in normal use, it pops up quite quickly when attempting more complicated/different AJAX-style lifecycles.

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


[jira] Commented: (MYFACES-1026) StateManager.restoreView has bad side effects

Posted by "Volker Weber (JIRA)" <de...@myfaces.apache.org>.
    [ http://issues.apache.org/jira/browse/MYFACES-1026?page=comments#action_12362725 ] 

Volker Weber commented on MYFACES-1026:
---------------------------------------

I have never tested 1.1.2  so far, 

but in the 1.1.1 behavior i don't see a problem.

if you runnig a own (e.g. Ajax) lifecycle, you are responsible for restoring the view at the end of your lifecycle.

You *need* to do this, if your ajax request changes and rerender any of the stored components
 like partial rendering of a panel component as done in tobagos sheet or tabgroup.



> StateManager.restoreView has bad side effects
> ---------------------------------------------
>
>          Key: MYFACES-1026
>          URL: http://issues.apache.org/jira/browse/MYFACES-1026
>      Project: MyFaces
>         Type: Bug
>   Components: Implementation
>     Versions: Nightly, 1.1.1
>     Reporter: Howard Abrams

>
> Calling StateManager.restoreView has the side effect of messing up the stored state.
> In 1.1.1, calling this method would remove the state from the session, and therefore it would be lost forever if the lifecycle didn't re-render causing the state to be re-stored.
> In 1.1.2, multiple states are now stored, but calling this method causes the index number of the current state to be incremented even though a new state may never be stored.
> While this bug isn't seen in normal use, it pops up quite quickly when attempting more complicated/different AJAX-style lifecycles.

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


[jira] Commented: (MYFACES-1026) StateManager.restoreView has bad side effects

Posted by "Howard Abrams (JIRA)" <de...@myfaces.apache.org>.
    [ http://issues.apache.org/jira/browse/MYFACES-1026?page=comments#action_12365300 ] 

Howard Abrams commented on MYFACES-1026:
----------------------------------------

Can the counter be per-view-ID instead of per session?

> StateManager.restoreView has bad side effects
> ---------------------------------------------
>
>          Key: MYFACES-1026
>          URL: http://issues.apache.org/jira/browse/MYFACES-1026
>      Project: MyFaces
>         Type: Bug
>   Components: Implementation
>     Versions: Nightly, 1.1.1
>     Reporter: Howard Abrams
>     Assignee: Mathias Broekelmann

>
> Calling StateManager.restoreView has the side effect of messing up the stored state.
> In 1.1.1, calling this method would remove the state from the session, and therefore it would be lost forever if the lifecycle didn't re-render causing the state to be re-stored.
> In 1.1.2, multiple states are now stored, but calling this method causes the index number of the current state to be incremented even though a new state may never be stored.
> While this bug isn't seen in normal use, it pops up quite quickly when attempting more complicated/different AJAX-style lifecycles.

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