> 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  (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
> 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 google-we...@googlegroups.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
Yes, this what I meant. I gave slightly incorrect description. Sorry.
Places are 'State' of a page, i.e. 'Place' in an application. This is
Also correct that set of Activities will describe components for the
current Place. Let us leave notion of mayStop() feature of
It is cool and it is actually applied if you change a *Place*.
But. You are in one Place in the application. You have a pager, for
example. What will you do in order to implement history (browser back-
forward) support for paging in this case?
For me personally: current page in URL is a *state* of some paginator
component managed by Activity. Not a new *Place*, correct?
So you'll have to have some functionality to write-read some params
for the paginator related to to current page. If you (nightmare!) have
What you'll have to do to be assured that sub-params (or there is an
other way to do it?) in the browser history string does not intercept?
> > What you'll have to do to be assured that sub-params (or there is an
> > other way to do it?) in the browser history string does not intercept?
> Create a specific Place that can hold those two "parameters" and navigate
> from place to place, changing only one value at a time?
> If you want to decouple your pagers from the places then, well, abstract
> that out behind some "navigator" component that'll manage the places for
> you (e.g. moveSecondPager(2) would navigate to a place with the same value
> for the first pager and the value 2 for the second pager; the "second
> pager" doesn't need to know about that).
This is a bad approach from my point of view (see big comment above).
Place should not depend or know anything about components inside of
it. It is mostly like marker.
When writing an application I don't want speak on a language of params
in URL, parsing those and update state of components.
I want to speak on a Object language. My object has a state - it saves
it, it restores it. Serialization is a lib's job.