Oh well - in case anybody is interested - I found a solution: view and
savedState can go out of sync simply because savedState might contain
an obj to be serialized, coming from a bean property.
In this case it appears that this obj is shared among any number of
saved state, even if they belong to different requests.
I use Trinidad with client state saving, which means that every page
contains a token, pointing to a session-bound serialized state.
Multiple requests imply multiple tokens, but they share the same copy
of a non-atomic serialized object. If this changes, then modifications
appear retrofitted to other state in cache, usually concerning previous
request/pages. If any related token is chosen because of browser
refresh, then view and state might go out of sync.
-- Renzo
Renzo Tomaselli wrote:
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.
|
