Re: [Myfaces] how to sync t:saveState with refreshed restore_view phase

[Renzo Tomaselli]

Hmmm ... not sure I understood. After all, I'm not even able to detect the "refresh situation". Basically I have two patterns: - restore view on submit, with consistent restored savedState. - restore view on refresh, with inconsistent restored savedState. In the latter case what is not consistent is really the restored view (older), not the savedState. Questions are: how can I distinguish those cases - then how can I give up either the old view or the savedState ? It would be enough to forget about the view to restore - much like it would be the very first visit on that page. To complete the picture - I use client state saving, as suggested by Trinidad. -- Renzo Werner Punz wrote: Renzo Tomaselli schrieb: Hi, I'm using t:saveState to persist a component/bean name pair across requests. Component inclusion occurs dynamically - according to the selected tab of a tabbed panel - by means of Facelets ui:include. Troubles occur while hitting the browser refresh button, since the restored view is older than what saveState contents state. While this refresh issue is a well known effect of JSF - I wonder about any way to invalidate/sync saveState contents. In case of dynamic inclusion, this mismatch leads to component/bean misalignement, since the restored view pretends to hold a component possibly different than restored state. I could even redirect a detected refresh to a stable page, but unfortunately view restoring occurs at the very beginning of the life-cycle. Or even better - I might force the view to be rebuilt from scratch - but I don't know how. Thanks for any help -- Renzo Well one easy way would be to use savestate in combination with some kind of stack, but also there is a save history, which is activated in server side state saving to handle the back buttons (in client side this is handled automatically), you might be able to access this one from the outside, but do not ask me how, maybe one of the other devs know it. Anyway the most likely workaround without accessing myfaces specific apis probably is to savestate some kind of value stack and in case of a refresh situation simply access the older value from the stack, I am not even sure if the history code doesn't already handle refresh situation already, you could give it a try.