Thursday, March 29, 2012

Re: GWT history handling library - give it a try

Thanks again

> > 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:,

(Throwing away a question if an application does not use Places and
Activities but instead loads it components 'by hands' (there is no GWT
support for history))

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


You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
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