So, for me to resume (my opinion): 1) Using components state for bookmarks is a bad idea - URL should contain only 'Place' information. If you need to have an ability to bookmark state different then initial page state - use different Place. As an example - if in a gmail I want to have a shortcut to some of my favorite folders (for example: https://mail.google.com/mail/#label/hello_thomas ;-) )- this is rather different Place, not a state of all Components on a page.
2) For a history navigation probably it would be better to have some key generated. Components states should be stored under that key (either in cookies or in HTMLs 5 browser cache) 3) If an application does not use Places and Activities - I should think what to do in that case. Will make necessary updates, though. thanks! On 30 mar, 17:09, Thomas Broyer <[email protected]> wrote: > On Friday, March 30, 2012 3:49:11 PM UTC+2, Kostya Kulagin wrote: > > > > > 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. > > A Place is a type-safe representation of the URL. No more, no less. If you > want to put something in the URL, then put it in a Place and have a > PlaceTokenizer transform it to your URL (and back when navigating to the > URL, either through a bookmark, link, or browser history). > > As I said, there might be cases where you want some history entries to > change the URL and some others that won't (but honestly, I still cannot > find any use case). In that case, I'd investigate HTML5's pushState to see > if it supports the use case, and if it does then simply punt for browsers > that don't support it (only handle the case where it changes the URL, i.e. > true navigation, not intermediate "state"). > I believe it'd be possible to mix a hidden iframe "hidden state change" and > manipulating the URL's #hash for "navigation", I'm really not sure it's > worth it => use pushState and let oldIE users with a "not as good" > experience as others (and possibly have them installChrome Frame, so you > could use pushState). > > And I still strongly believe that if you have two truly independent things > on a page, only one should affect the browser history, or you have a > serious design issue ("Er, I clicked the back button 3 times, now if I > click it once more, will it change the left side or the right side of the > screen?"). > That was the main issue with frames (apart from "addressability", i.e. > "bookmarkability"), that are now officially dead (as > in:http://www.w3.org/TR/html5/obsolete.html#frames) > > Of course, YMMV. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
