Thursday, March 29, 2012

Re: GWT history handling library - give it a try

On Thursday, March 29, 2012 5:14:28 PM UTC+2, Kostya Kulagin wrote:
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?

If you want your state to be bookmarkable, then you'll navigate to another place. What's wrong with that?
(and note that changing place does not necessarily mean starting *new* activities)
For me personally: current page in URL is a *state* of some paginator
component managed by Activity. Not a new *Place*, correct?

No. If it's in the URL, it *locates* something (URL = Uniform Resource Locator; URI = Uniform Resource Identifier), so that you could send the link via mail or IM and *go to* that... place!

There are cases where you'd want entries in the browser history without changing the URL; for that GWT provides no support at all (Closure Library does, for instance; but you cannot mix history-without-url-changing and changing-url-to-reflect-app-state in the same app –I wonder how HTML5's pushState works without changing the URL–). But that's not what you're talking about here.

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
2 paginators?

Well, honestly, if you have to pagers *and* you want them to both create entries in the browser's history, you have a design issue!
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).

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