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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
