Wednesday, March 28, 2012

Re: GWT history handling library - give it a try

On Wednesday, March 28, 2012 4:42:07 PM UTC+2, Kostya Kulagin wrote:
> As for the general approach (from what I can read from the wiki pages), I
> don't think it really "works". Do you really want to save the open/close
> state of each tree item in the browser's history? Navigating the app would
> quickly become a nightmare. URLs are for navigation, not about application
> state. This is why the HTML5 History API provides a specific argument in
> pushState() to store some state independently of the URL: there are things
> that you want to keep around as long as the app is "running" but that don't
> need to be carried along in the URL if you bookmark it or copy/paste it to
> a mail or IM.
> As for combining the state of several components into the URL (as the YUI
> Library provides, for instance), that makes ugly URLs that don't carry any
> "real" meaning; not quite "Cool URIs" [3,4].
> URLs are for navigation, and GWT provides a cool way of handling it for
> quite some time now: Places [5] (and if you ask me, you should use
> Activities too, but that doesn't fit everyone, so feel free to use GWTP,
> Mvp4g or whatever)
Again good points, again thank you.
Places are intended to descibe set of components on page but not their
(components) state.

No. Activities are a set of "components" on the page. A Place, by definition, describes the "location" within the app, which you can interpret as being the "state" of the app, thus the "state" of the activities (it's rather the other way around though: you navigate to some place, and activities will construct their state from the current place)
Have a look there for more details:, and then

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

No comments:

Post a Comment