To Make it more clear for everyone.
If I Implement below mentioned code in my application.
Window.addWindowClosingHandler(new Window.ClosingHandler() {
@Override
public void onWindowClosing(ClosingEvent
event) {
event.setMessage("Are you sure ?");
}
});
Window.addCloseHandler(new CloseHandler<Window>() {
@Override
public void onClose(CloseEvent<Window> event)
{
}
});
User is presented with a Confirmation dialog and If he says stay on
this page , then Nothing happens.
I would like to know which code can be written to have the same
behaviour without having need of any confirmation dialog.
Is there any JSNI OR any way by which we can have the same behaviour
achived wihtout any dialog.
On Feb 17, 12:45 pm, Sky <[email protected]> wrote:
> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
