t:saveState works with tabs - but I don't know why!

[Phil Stone <pk...@ucdavis.edu>]

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

Re: t:saveState works with tabs - but I don't know why!

[Werner Punz <we...@gmail.com>]

Just to the second info, there is a ui:debug tag in myfaces 2.0, it in 
fact is a facelets tag, someone just posted a patch which adds the 
safestating information to it, it might get integrated soon.

Not sure what ui:debug generally exposes, I have not used it myself yet.


Werner


Am 16.06.10 17:54, schrieb Werner Punz:
> Hi my personal guess is this also works for server side state saving,
> since in server side statesaving the viewState basically just is an
> encrypted token pointing towards the correct state on the server which
> has to be restored.
>
> Werner
>
>
> Am 16.06.10 17:19, schrieb Phil Stone:
>> 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
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

Re: t:saveState works with tabs - but I don't know why!

[Werner Punz <we...@gmail.com>]

Hi my personal guess is this also works for server side state saving, 
since in server side statesaving the viewState basically just is an 
encrypted token pointing towards the correct state on the server which 
has to be restored.

Werner


Am 16.06.10 17:19, schrieb Phil Stone:
> 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
>>>
>>
>>
>>
>
>

Re: Re: t:saveState works with tabs - but I don't know why!

[Phil Stone <pk...@ucdavis.edu>]

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
>>
>
>
>

Re: t:saveState works with tabs - but I don't know why!

[Werner Punz <we...@gmail.com>]

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
>