On 29 mar, 19:49, Thomas Broyer <t.bro...@gmail.com> wrote: > 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) > Thanks. Agreed with bookmarks - they probably should not contain a state of components... Or at least should not be handled in most cases. You navigate to some place - you get it. With pager on the first page, with the first opened tab. Indeed the question is - what is Place. Should it contain information required for components which are registered to this place? For me Place is a separate this. Like marker. Like some new URL to which you register Components through activities. But. For history support (back-forward btns) you should have an ability somehow modify history string. Yes? And it is not a Place. And not connected to Place notion. It is connected to Component. I agree with you that such URLs like 'a=b&c=d' etc in history string are ugly. And in general concept agree that for bookmarks you generaly speaking should not care about state of a component within Place. You are bookmarking Places, not component states (thanks to Jens). But I have to have some support for back-forward browser buttons. And should not have such ugly URLs. One of possible things is storing some generated key in URL in *additions* to Place and store components data in Cookie for example. Or in a local storage (HTML5). This is about Places. If an application does not use Places and Activities then there should be some 'intermediate' solution.
> 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. > I've started - see above. You and Jens convinced me that worrying about staring namely components state in bookmarks bad idea. Thank you! > 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! > Let me disagree. I'd like to have browsers buttons support for paging. And I really can imaging other cases when it could be suitable. > > 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. thank you again - really helping comments. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. 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.
