Oh, and your requirement seems like premature optimization or you need to rethink your architecture.
There is no way that keeping track of a session handle should be taking up any memory on the client side. You should be using database for your persistance layer - the database should cache your most frequently used sessions for you. The approach I like is I try to keep the server stateless - all the state goes into the client with the server simply validating & storing/fetching data & a simple RPC layer for session authorization (which is just a randomly generated ID stored in the database with information needed for authorization - the session id gets passed as a cookie although the GWT gods say to not use cookies for security reasons & instead pass it directly in the RPC code) & calling the backend. On Wed, Apr 1, 2009 at 10:09 PM, Vitali Lovich <vlov...@gmail.com> wrote: > GWT is javascript. You can leverage all your Javascript code from the GWT > framework. That being said, you're pretty much SOL on notifying the server > on a page refresh. I believe, although not 100% sure, that you cannot do > anything* while the page is closing (which is what happens from the > perspective of Javascript). > > The ONLY one that can detect the client closing is the server through a > heartbeat (in other words, you can only approximate - and if you're wrong > you've got to handle it gracefully on the client side by informing them > their session timed out). > > * DOM manipulation & any kind of network communication. > > http://www.telerik.com/help/aspnet-ajax/ajxmozillacancelrequest.html > > > On Wed, Apr 1, 2009 at 4:58 PM, bigtruckdriver <adam.ludg...@gmail.com>wrote: > >> >> I do have some server-side cleanup functionality which is basically a >> session expiry, but this application is going to be needing every >> advantage it can get in terms of server memory, so I need this close >> window cleanup to occur as well (even though it's not a guarantee that >> it will work every time, as Luke mentioned). >> I think the only solution here is to call some javascript outside GWT >> that can detect a page refresh. >> >> On Mar 27, 3:58 pm, Vitali Lovich <vlov...@gmail.com> wrote: >> > The way I solve this is that a timer on the server cleans up sessions >> > that haven't had activity in a while. >> > >> > It's a little bit simpler for me since I have a stateless setup with >> > the session id simply being used for authentication purposes. >> > >> > I think that's the most robust approach - you don't need to maintain >> > complicated state information in the server. You simply have a >> > permissions based approach as to whether or not a user is allowed to >> > modify global resources & the client-side takes care of state. >> > >> > On Fri, Mar 27, 2009 at 4:23 PM, lukehashj <bobwazn...@gmail.com> >> wrote: >> > >> > > You can not rely on this event being raised before the browser is >> > > closed. You can use the onunload="someJavascript()" on your body tag >> > > and then some JSNI to call your google code. >> > >> > > Here's the problem: the event gets raised, and you start doing your >> > > work. The window gets closed before you finish doing your work, and >> > > your rpc never completes and the server never knows. >> > >> > > I'd say at best you get a 50% success rate with the window close >> > > events :) >> > >> > > -luke >> > >> > > On Mar 26, 3:58 pm,bigtruckdriver<adam.ludg...@gmail.com> wrote: >> > >> I'm in a similar predicament, perhaps you might have an idea of what >> > >> to do. >> > >> > >> When the user closes the browser window, I want the application to >> > >> logout his/her session automatically so as to free up memory on the >> > >> server from their session. So I use the onWindowClosed() function to >> > >> take care of this... But when the page is refreshed, the session gets >> > >> logged out as well through the same function. This is something I >> want >> > >> to stop from happening. Any suggestions? >> > >> > >> On Mar 15, 9:26 am, Rohit <rohitsmart...@gmail.com> wrote: >> > >> > >> > Hi >> > >> > There is no way in GWT to distinguish betweenRefreshbuttonclick and >> > >> > Window closebuttonclick. But you can trackrefreshbuttonwith a >> > >> > little trick. You should use a time cookie which will expire after >> > >> > some time. So whenrefreshbuttonis pressed, in on module load of >> > >> > entry point , track the value of this cokkie, if this cookie is >> still >> > >> > alive, this meansrefreshbuttonis pressed. The time this cookie will >> > >> > expired should be considered. It should be very little. >> > >> > >> > Second for history, you should save your information in Session on >> > >> > window close and then ifrefreshbuttonis pressed, get your >> > >> > information from this session. >> > >> > >> > Thanks and regards >> > >> > >> > Rohit >> > >> > >> > On Mar 14, 2:30 am, "levi.bracken" <levi.brac...@gmail.com> wrote: >> > >> > >> > > You can restore state, but it's a bit more work than just using >> GWT >> > >> > > History. Basically you'll need to come up with some way of >> modifying >> > >> > > the url search parameter (stuff after the #) to include some info >> so >> > >> > > that you can bring the userbackinto the same state as they were >> > >> > > before. For example, if your application has a number of >> screens and >> > >> > > they were on screen foo, which was loading with properties for an >> item >> > >> > > with id 10 then you'd need that information in the Url. >> > >> > >> > > ex: http://yourApp.com/gwtHostPage.html#screen=foo_id=10 >> > >> > >> > > You could also put a conversation id in the url param and then >> keep >> > >> > > the fine details cached on the server, but that makes the >> state/data >> > >> > > more transient. If you go with an option like this though it can >> help >> > >> > > make your pages open and work in other tabs and even make points >> in >> > >> > > your application bookmark'able'. >> > >> > >> > > Now for the easy answer, yes you can just prevent the user from >> > >> > > carelessly clickingrefresh. Fortunately there isn't a way to >> trap >> > >> > > somebody on a webpage (think about how bad the web would be). >> But, >> > >> > > you can use the WindowCloseListener to present a user with a >> > >> > > confirmation before they close the window, navigate to a new >> page, or >> > >> > > hitrefresh. It'd look something like this (not tested): >> > >> > >> > > ///////////////////////// >> > >> > > Window.addWindowCloseListener( >> > >> > > new WindowCloseLisener(){ >> > >> > >> > > public String onWindowClosing(){ >> > >> > > return "Are you sure you want to leave this application?"; >> > >> > > } >> > >> > >> > > public void onWindowClosed(){ >> > >> > > // Cleanup if need be >> > >> > > }}); >> > >> > >> > > //////////////////////////////// >> > >> > >> > > On Mar 13, 2:52 pm, dodo <rajd...@gmail.com> wrote: >> > >> > >> > > > GWT provides History.onHistoryChange event to handle history >> but how >> > >> > > > can we restore application state when a user clicks >> onRefreshbutton? >> > >> > > > For example the user performed multiple actions on the web site >> and >> > >> > > > then clickedrefreshbutton. Now how using GWT History class we >> can >> > >> > > > restore the same state? >> > >> > >> > > > Another question, is there a way to trap "Refresh" click before >> > >> > > > actually the app refreshes and can be cancel the event? >> > >> > >> > > > Rajesh- Hide quoted text - >> > >> > >> > > - Show quoted text - >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
