Thank you for a response. If I understood you correctly - you propose some kind of Place which will contain props of all components. (sorry if I misunderstood you) Personally myself don't like this solution. Place has nothing to do with its components state.
When writing an application I don't want speak on a language of params in URL, parsing those and update state of components. I want to speak on a Object language. My object has a state - it saves it, it restores it. Serialization is a lib's job. This is an idea. thanks! On 2 avr, 11:33, Kostya Kulagin <kkula...@gmail.com> wrote: > 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 <t.bro...@gmail.com> 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 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.
