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 <mikej1...@gmail.com> 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 <ranjan.n...@gmail.com> 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 <mikej1...@gmail.com> wrote:
> > > Don't get it. Please show your good design in an understandable style.
>
> > > On Fri, May 28, 2010 at 4:49 PM, federico <federico.mona...@gmail.com
> > >wrote:
>
> > > > bad design.
> > > > "refresh" is a feature and you should provide bokmarkable refresh-save
> > > > pages.
>
> > > > On 28 Mag, 20:42, Mike J <mikej1...@gmail.com> 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
> > google-web-tool...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs
> > > > cr...@googlegroups.com><google-web-toolkit%2Bunsubs
> > cr...@googlegroups.com>
> > > > .
> > > > 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 google-web-tool...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs
> > cr...@googlegroups.com>
> > .
> > 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 google-web-tool...@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.
