Niraj You're problem is two fold. As already mentioned you need to be auto logging the user back in when they refresh the page. Think about how any other ajax app works, including the newer version of google groups. I'm logged in and if I hit F5 I stay logged in. There has to be a session cookie and the app checks to see if that cookie exists (then it hasn't expired) and then load up that user's user-specific data. The user shouldn't see the log in page again unless the cookie has expired. So make sure you know how and when the session cookie expires. 20 minutes since last user activity is usually the earliest a session cookie expires, but you have to choose how long it is. Nothing wrong with having an indefinitely long session (never expires) if the site doesn't contain highly sensitive information (banking, etc).
The next part of the problem is that you don't like it that you are losing not only the history state (the "page" the user had navigated to in the web app) but you are also losing the user specific data that is stored in JS variables. You need to control both of these. You need your history management to read the hash value in the URL and rebuild the site to the "page" the user had been at before the page refresh. Not exactly easy to do, but you're gonna have to get that working. Next, you're going to have to decide how you want to maintain those variables that are in JS. There are typically 3 options. Cookies, server session/DB storage, or local storage. I don't know anything about local storage, since it's pretty brand new (I know chrome supports it, but I don't know what other browsers do, if any (the others probably do or will soon)). Cookies are easy and not a bad option depending on the usage. You could use them as temporary storage so that refreshing the page wouldn't kill all the work done by the user. But you'd need to be sure you don't leave any cookies lying around as the user navigates the app. Each "page" of your app could store values entered in cookies until they click the Save/Cancel button, at which point you delete the cookies. Make sure you delete those cookies when the user simply navigates away to another "page" on your app. Remember, cookies are sent along with any and all server requests, so if you've got 200 cookies, they are all going to go on the ride on a simple RPC and seriously increase traffic latency. The most common solution is storing the values on the server. You can easily RPC user entered data to the server between user entries with tons of time to spare. User input is so slow compared to simple RPC service requests. The same idea as saving and deleting cookies applies here. It's just temporary session data that shouldn't persist between "pages" otherwise it's a waste of memory. Although, it's a pretty good idea to basically do away with the Save button by simply saving the user entered data straight away to the server DB, rather than just saving it as temporary session data. Then you don't even have to worry about managing the temporary data. This is what I highly recommend. But it depends on the app and what you are trying to accomplish. Lastly, I do know of a fool proof way to prevent any attempts to leave the website you are on, including refreshes or even changing the URL in the address bar. However this is BAD and you most definitely should NOT be doing that in your scenario. You need to implement something along the lines of what I've already said, because that's how everyone else does it. gl! -- 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.
