You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Michael Heinen <mh...@recommind.com> on 2008/04/18 11:18:42 UTC
multiple windows - view not restored
Hi all,
I have a JSF1.1 app where the user can switch into a two window mode.
The first window contains a list with items and options and the 2nd
window contains a detail view of the selected item in window1.
If an item is selected in window1 via ajax then this window calls in the
oncomplete phase via javascript another ajax link in window2 in order to
refresh it.
This is working very well in about 90% of the time.
The number of views in session is set to 1 and I user server-side state
saving.
THE PROBLEM:
- command is clicked in window1 which forces afterwards a command
execution from window2 via javascript
(means view2 is the last one accessed)
- browser is not touched for a few minutes
- command is clicked in window1 ---> view1 cannot be restored
I heard that the views are stored as weak references and therefore I
assume that view1 is garbage collected which explains the time
dependency.
Now I see following alternatives:
a) set number of views in session to 1 to 2
b) try to execute all commands from window1 via javascript by using the
window.opener in window2.
This will be quite some work and I don't know whether the opener is
always available and whether this is smooth enough.
Ajax cannot be used to update another window with the target attribute
therefore I would have to update always window1 and then manually update
the DOM in window2 via js.
Questions:
1) Is (a) a possible solution or does it have any side effects except
memory consumption?
2) are there any other alternatives that I don't know for this use case?
3) Updating to jsf 1.2 is currently not an option unfortunately.
Multiple windows are supported there but how does this work exactly
and where are window ids specified?
Environment: myFaces 1.1.5, tomahawk 1.1.5, JSPs, ajax4js4 1.1.1 -
richfaces 3.1.4
Cheers,
Michael
RE: multiple windows - view not restored
Posted by Michael Heinen <mh...@recommind.com>.
Thanks Simon.
Clientsid state saving is also no alternative due to performance issues.
It did also not help to increase the number of views in session from 1 to 2.
I noticed during debugging JspStateManagerImpl that there are e.g. two views stored for window2.jsp with different sequenceIds.
The class SerializedViewKey consists of a view id (e.g. window2.jsp) and a sequenceId.
What is this sequenceId ?
Moreover my approach with 2 views in session can't work: I navigate to other views in the main window and then the view of window2 could be lost.
I'll try to extend JspStateManagerImpl for my usecase and maybe there is a way to store views for windows.
I'll try to use a key inside the request path to identify requests from window2.
Is it possible to obtain the name of the submitted form on server side?
Is anybody else aware of multi-window support in JSF1.2 ?
Michael
-----Original Message-----
From: simon.kitching@chello.at [mailto:simon.kitching@chello.at]
Sent: Freitag, 18. April 2008 11:44
To: MyFaces Discussion
Subject: Re: multiple windows - view not restored
Michael Heinen schrieb:
>
> Hi all,
>
>
>
> I have a JSF1.1 app where the user can switch into a two window mode.
>
> The first window contains a list with items and options and the 2nd
> window contains a detail view of the selected item in window1.
>
> If an item is selected in window1 via ajax then this window calls in
> the oncomplete phase via javascript another ajax link in window2 in
> order to refresh it.
>
> This is working very well in about 90% of the *t*ime.
>
>
>
> The number of views in session is set to 1 and I user server-side
> state saving.
>
>
>
> THE PROBLEM:
>
> - command is clicked in window1 which forces afterwards a command
> execution from window2 via javascript
>
> (means view2 is the last one accessed)
>
> - browser is not touched for a few minutes
>
> - command is clicked in window1 ---> view1 cannot be restored
>
>
>
> I heard that the views are stored as weak references and therefore I
> assume that view1 is garbage collected which explains the time dependency.
>
>
>
> Now I see following alternatives:
>
> a) set number of views in session to 1 to 2
>
> b) try to execute all commands from window1 via javascript by using
> the window.opener in window2.
>
> This will be quite some work and I don’t know whether the opener is
> always available and whether this is smooth enough.
>
> Ajax cannot be used to update another window with the target
> attribute therefore I would have to update always window1 and then
> manually update the DOM in window2 via js.
>
>
>
> Questions:
>
> 1) Is (a) a possible solution or does it have any side effects except
> memory consumption?
>
> 2) are there any other alternatives that I don't know for this use case?
>
> 3) Updating to jsf 1.2 is currently not an option unfortunately.
>
> Multiple windows are supported there but how does this work exactly
> and where are window ids specified?
>
>
>
> Environment: myFaces 1.1.5, tomahawk 1.1.5, JSPs, ajax4js4 1.1.1 -
> richfaces 3.1.4
>
In your specific case, then I think your analysis of the problem
(garbage collection) is correct, and that setting number of views to 2
should work. The only side-effect is a minor increase in memory usage.
However if the user can navigate to different views in this secondary
window, or if you want the ability to do a submit from the secondary
window *after* the user has used the primary window to visit some other
pages then client-side state-saving *must* be used.
The HTTP protocol provides absolutely no reliable way to tell which
window a command came from. Therefore there is no way for any
server-side caching mechanism to ensure that at least one view is
retained in the cache for each window; the server just does not know
which window a view is associated with. Well, at least no-one has found
a solution for this yet AFAIK. So currently just the N *most recently
visited* views are kept, regardless of window. Client-side state of
course solves this by cleanly holding a different copy of the state per
window; no need for the cache to detect which window is which.
I don't know of anything in JSF1.2 that makes it different from JSF1.1
in this area.
Regardless of whether you use client-side or server-side state saving,
you must be extremely careful about session-scoped beans if multiple
windows exist. The Orchestra library can help with this issue by
providing an alternative to session scope. But Orchestra does not
(currently) make server-side state-saving for the JSF component tree any
safer; again, client-side state is the only working solution.
Regards,
Simon
Re: multiple windows - view not restored
Posted by "simon.kitching@chello.at" <si...@chello.at>.
Michael Heinen schrieb:
>
> Hi all,
>
>
>
> I have a JSF1.1 app where the user can switch into a two window mode.
>
> The first window contains a list with items and options and the 2nd
> window contains a detail view of the selected item in window1.
>
> If an item is selected in window1 via ajax then this window calls in
> the oncomplete phase via javascript another ajax link in window2 in
> order to refresh it.
>
> This is working very well in about 90% of the *t*ime.
>
>
>
> The number of views in session is set to 1 and I user server-side
> state saving.
>
>
>
> THE PROBLEM:
>
> - command is clicked in window1 which forces afterwards a command
> execution from window2 via javascript
>
> (means view2 is the last one accessed)
>
> - browser is not touched for a few minutes
>
> - command is clicked in window1 ---> view1 cannot be restored
>
>
>
> I heard that the views are stored as weak references and therefore I
> assume that view1 is garbage collected which explains the time dependency.
>
>
>
> Now I see following alternatives:
>
> a) set number of views in session to 1 to 2
>
> b) try to execute all commands from window1 via javascript by using
> the window.opener in window2.
>
> This will be quite some work and I don’t know whether the opener is
> always available and whether this is smooth enough.
>
> Ajax cannot be used to update another window with the target
> attribute therefore I would have to update always window1 and then
> manually update the DOM in window2 via js.
>
>
>
> Questions:
>
> 1) Is (a) a possible solution or does it have any side effects except
> memory consumption?
>
> 2) are there any other alternatives that I don't know for this use case?
>
> 3) Updating to jsf 1.2 is currently not an option unfortunately.
>
> Multiple windows are supported there but how does this work exactly
> and where are window ids specified?
>
>
>
> Environment: myFaces 1.1.5, tomahawk 1.1.5, JSPs, ajax4js4 1.1.1 -
> richfaces 3.1.4
>
In your specific case, then I think your analysis of the problem
(garbage collection) is correct, and that setting number of views to 2
should work. The only side-effect is a minor increase in memory usage.
However if the user can navigate to different views in this secondary
window, or if you want the ability to do a submit from the secondary
window *after* the user has used the primary window to visit some other
pages then client-side state-saving *must* be used.
The HTTP protocol provides absolutely no reliable way to tell which
window a command came from. Therefore there is no way for any
server-side caching mechanism to ensure that at least one view is
retained in the cache for each window; the server just does not know
which window a view is associated with. Well, at least no-one has found
a solution for this yet AFAIK. So currently just the N *most recently
visited* views are kept, regardless of window. Client-side state of
course solves this by cleanly holding a different copy of the state per
window; no need for the cache to detect which window is which.
I don't know of anything in JSF1.2 that makes it different from JSF1.1
in this area.
Regardless of whether you use client-side or server-side state saving,
you must be extremely careful about session-scoped beans if multiple
windows exist. The Orchestra library can help with this issue by
providing an alternative to session scope. But Orchestra does not
(currently) make server-side state-saving for the JSF component tree any
safer; again, client-side state is the only working solution.
Regards,
Simon