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 
> great. 
> Also correct that set of Activities will describe components for the 
> current Place. Let us leave notion of mayStop() feature of 
> Activities. 
> 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 
https://groups.google.com/d/msg/google-web-toolkit/-/W-ESf1Wufq8J.
To post to this group, send email to google-web-toolkit@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.

Reply via email to