Hi,
The solution I use is to put a ping script in the page which sends a
request to the server every couple of minutes. With that, the session
never times out while the browser window is open, and so the problem
never occurs.
Of course this requires javascript, but is javascript is disabled then
Suggestion:
1 - add a javascript state change listener;
2 - check the contents of the request using TrXMLRequestEvent
getResponseText() and/or getResponseStatusCode()
3 - if the result isn't a PPR result, notify the user or send the browser to
a specified url.
I'm planing to write something like
so that the refresh will re-run the search
and
not show the Find screen?
Thanks,
Chris
--
View this message in context:
http://www.nabble.com/Refresh-View-after-HTTPSession-Timeout-tp11366195p22478775.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
My guess is that your timeout-handling approach is failing to work with
any AJAX or frame-based pages, and that these tabs are just one case
where ajax or frames are being used.
The problem is that when a browser is refreshing a whole page, a filter
can return an http-redirect command and the
the search
and
not show the Find screen?
Thanks,
Chris
--
View this message in context:
http://www.nabble.com/Refresh-View-after-HTTPSession-Timeout-tp11366195p22490246.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
I have a generic search screen (standard input form) that displays the
results on the next page using a tr:table.
If the user hits the refresh button any time prior to the HTTPSession
timeout, then the form is resubmitted and the search generated again (could
display different results if the
Hello Chris,
I don't see any easy way as if the session timed out you have no way to
associate the request with the user therefore you cannot know what the user
was searching. You could always persist that data elsewhere, but you would
still have the problem of linking that info to the incoming
I have a generic search screen (standard input form) that displays the
results on the next page using a tr:table.
If the user hits the refresh button any time prior to the HTTPSession
timeout, then the form is resubmitted and the search generated again (could
display different results if the
That's what I was afraid the answer was going to be. I was hoping since
all of the data parameters were passed back in on the browser refresh that
there might be something I could do.
I've thought about the increasing the timeout (which is 30 minutes right
now), however to make sure the user
.
You can also use the t:saveState tag as in...
t:saveState id=saveDialogBean value=#{dialogBean}/
Marty
Chris Hane [EMAIL PROTECTED]
06/29/2007 02:49 PM
Please respond to
MyFaces Discussion users@myfaces.apache.org
To
MyFaces Discussion users@myfaces.apache.org
cc
Subject
Refresh View after
Hey Chris, it's kind of hokey, but if your url contains all the data
you need you might be able to create a bunch of managed properties on a
managed bean and bind them to the request parameter mappings. You could
then use that managed bean to populate the values in your components. :)
Scott - thanks for the pointer.
I actually ended up doing something very similar by using a feature of Seam
that in essence let's me do this without any extra coding on my part.
There is a feature called Page Actions that let's me associate parameters
(and a whole bunch of other stuff) with a
View after HTTPSession Timeout
I have a generic search screen (standard input form) that displays the
results on the next page using a tr:table.
If the user hits the refresh button any time prior to the HTTPSession
timeout, then the form is resubmitted and the search generated again
13 matches
Mail list logo
