[ 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
