Thanks, everybody. I have to do that way probably later. Mike J.
On Tue, Jun 1, 2010 at 10:03 AM, Ranjan <[email protected]> wrote: > Simply put, it is impossible to avoid Page reload if the User clicks > the 'Refresh' button on the browser. There is no way to avoid it if > the user wants to refresh the page. > > And yes, when the page is refreshed, every object contained within the > Page is lost. So you will have to create the whole page from the > scratch. > > Now the problem you are facing (as I have understood) is, as the user > works on your application, a number of widgets are created, removed, > moved from one place to another, so on. And if at any point, the user > Refreshes the page, your page would start up with the initial > condition. > > This is normally solved by using history tokens. Now when I say saving > a state, I meant saving it in a small piece of string, that would be a > part of the URL (Something like #page/10caf10b or #navigation/91abc, > etc). Now this small bits of information are usually sufficient for > loading the entire page. It might make few ajax calls with the server. > Sessions are used in cases like this. > > And believe me a very complex applications could be developed using > just small bits of tokens that can easily be accommodated in the URL > itself. Take GMail for example. You can just browse through different > states of the Gmail application, and if you press refresh button at > any state, you will get the same page when it refreshes. > > I hope you got my point. > > Page reloading is something that is done by the User and it can't be > avoided. Its up to the programmer that the user receives the same > interface even if he/she refreshes the page at any state of the > application. > > > On Jun 1, 6:43 pm, Mike Jiang <[email protected]> wrote: > > Thanks for a clear desc. What I'd like to say is that the "refresh-save" > is > > not a new scenario at all for web apps. Actually I have heavily used the > > history tokens for back/forward/reloading following the sample code of > GWT > > ShowCase. But saving states is a subtle thing for a stateful app. Accord > to > > the info found, there are some concerns when doing historical > > back/forward/reloading, > > > > 1). reloading is equivalent to rebooting of an operating system or > closing > > of an app, implies lost every and each bit in nature; > > 2). reloading is a feature of the "traditional" web app with multiple > > separate web pages, not a preferred one for ajax apps since a GWT project > > has only one html file; Actually it was said that the reloading was used > > less and less in ajax apps if not totally abandoned; > > 3). Saving the states before reloading is not a simple task to do for a > > dynamic loaded screen; so does for loading states back and re-displaying > the > > state exactly; > > 4). there remains an issue for where the states are saved. Save them to > the > > server side or save it as cookie on the client side? a fashionable way is > to > > save the states to the persistence on the server side; > > 5). saving states involves saving all the state data from every possible > > screen the app might have, which is not a simple job; > > > > I have studied the example of the ShowCase and found that the app > actually > > loads every possible content screen into a collection and adds them all > as > > history tokens while the app initializes. This is good for a small app > but > > not preferable for a very large web project for sure. > > > > Secondly it's found when clicking the reloading button from the browser, > > actually the app only reloads the content widget with "static" data, not > > exactly re-display the previous state. You can see it by clicking the > > "Source Code" tab then pressing "reload" button. > > > > Welcome any comments. > > > > Thanks, > > > > Mike J. > > > > Based on the above points, I want to avoid reloading or refreshing and > let > > the page simply stays as it is. It's a lazy person's scenario. It might > be > > totally wrong. But I have not been convinced what's the fatal error in > this > > method. > > > > > > > > On Mon, May 31, 2010 at 10:53 PM, Ranjan <[email protected]> wrote: > > > It is not possible to avoid refresh(reload) through scripts. The only > > > possible thing is you could display an alert message through the > > > browser which provides the User with option to either stay on the page > > > or leave it. Which is what is done in the CloseHandler in your example > > > script. > > > > > What federico wants to say is you should use history-tokens to save > > > your states. > > > history > > > Use Refresh, Back, Forward as a feature and not a catastrophe, with > > > the the help of GWT History support. > > > > > On Jun 1, 6:57 am, Mike Jiang <[email protected]> wrote: > > > > Don't get it. Please show your good design in an understandable > style. > > > > > > On Fri, May 28, 2010 at 4:49 PM, federico < > [email protected] > > > >wrote: > > > > > > > bad design. > > > > > "refresh" is a feature and you should provide bokmarkable > refresh-save > > > > > pages. > > > > > > > On 28 Mag, 20:42, Mike J <[email protected]> wrote: > > > > > > Hi, > > > > > > I ran into a problem about clicking the "reload" button on a > web > > > > > > browser. > > > > > > > > My app is a stateful GWT app. Users need to be authenticated > for > > > > > > login. After login they can surf on various pages. But users > > > sometimes > > > > > > were used to press the "reload" button on the browser to refresh > the > > > > > > page. > > > > > > > > The reloading process just bring the screen back to a reboot > > > state, > > > > > > with all state info lost. That's not what we expect. > > > > > > > > The quick solution is, catch the reload event before the > browser > > > > > > sends the "reload" request to the web server and prevent the > browser > > > > > > from sending it. > > > > > > > > I have read the relevant posts in this group and found the > useful > > > > > > info that "reload" event is equivalent to the Window Closing > event. > > > So > > > > > > in the following code snippet I can catch the event, > > > > > > > > Window.addCloseHandler(new CloseHandler<Window>() { > > > > > > public void onClose(CloseEvent<Window> event) { > > > > > > //prevent browser sending the reload request to > the > > > > > > web browser > > > > > > } > > > > > > }); > > > > > > > > But I don't know how I can stop the browser from sending the > > > > > > "reload" request to the web server. > > > > > > > > Thanks for any help, > > > > > > > > Mike J. > > > > > > > -- > > > > > 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]<google-web-toolkit%[email protected]><google-web-toolkit%2Bunsubs > [email protected]><google-web-toolkit%2Bunsubs > > > [email protected]> > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > > > -- > > > 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]<google-web-toolkit%[email protected]><google-web-toolkit%2Bunsubs > [email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > -- > 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]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- 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.
