Thanks for replying, Werner. I'm back at work now, and your reply made
me doubt whether the uid I added to the page had any effect at all.
I've removed it, and the initializing code, and tab state seems to
remain intact and unaffected by other tabs. So this is all free due to
client-side state saving? Wonderful! If anyone has any details on
this, I'd be interested to learn more about it.
I still would love to be able to diagnose the view tree if anyone has
any tool suggestions for doing that.
Thanks again for the reply.
Phil
On 7/22/64 11:59 AM, Werner Punz wrote:
Are you on client side state saving, in client side the entire state
is saved into the viewstate element of the form.
So Multi window/tab handling is a non issue there.
In server side the viewstate is just used to connect the client to the
correct viewroot on the server.
(I assume myfaces has some special handling for multi windows in this
case to add a random token to the viewstate, but I have never had a
look at the part of the code, so I am not sure either)
Werer
Am 12.06.10 00:46, schrieb Phil Stone:
Hello,
Using myfaces 1.2.8 and tomahawk12 1.1.9, I've implemented a JSF page
with a request-scoped backing bean and which employs t:saveState to hold
some of the page's state between requests. My original goal was to find
a way to allow multiple tab/window-copies of the page to act
independently without the cross-talk that occurs in a session-scoped
backing bean across windows/tabs.
I thought I had hit a setback when I realized that the "id" parameter
for t:saveState could not be an EL expression -- I had originally
intended to use a window UID as an EL expression to differentiate
storage objects between tabs/windows; without such differentiation,
surely each tab/window would overwrite the single storage object with
its own data. This was indeed the case; switching tabs mixed the state
information between the tabs.
Then, in preparation for another line of attack, I added a hidden field
on the JSF; I initialize this hidden field with the current time when
the page is first accessed via URL. I intended to use these as UIDs for
an array of state-saving objects, one for each tab/window, that got
saved in its entirety in the t:saveState object. I really dreaded
implementing such a monster, btw. However, just adding this unique id in
a hidden field somehow made state-saving work independently across tabs
and windows!
I'm very happy that this works, and very uncomfortable not understanding
why. Can anybody shed some light on this little miracle for me? Are
there somehow separate view trees (where t:saveState stashes the
persistent object) for each tab/window now, just because of the hidden
uid? Or (this seems less likely to me) are there separate saveState
objects for each window/tab (why would there be)?
As an aside, I'd really love to be able to look at the state of the view
tree to figure this out; does anyone know of a way to do that?
Thanks,
Phil
