To be clear, I looked into your library. If I understand it correctly what you do (just like in the sample I posted above) is to map an URL from/to a ComponentState, which has a representation of the state of the object as a Map<String, String>. Your ComponentState is at last a wrapper of the string map. A Place is similar in concept, with the difference that you don't have just a Map<String, String> but a series of methods to have the properties with their correctly typed class.
The ComponentStateSerializer builds an history token using that map, or breaks your current history token to the map. This is the same as a PlaceTokenizer will do, with the difference that the PlaceTokenizer returns a Place, which is a typed object and has typed accessors. Your library is very similar tho the one I developed when Places were not in GWT, and if you look at my code above you'll notice it's similar to your DefaultComponentStateSerializer.toHistoryString(ComponentState ), the only difference being some more configuration options for yours. Just spend a couple of hours trying out the Places tutorial Thomas Broyer posted and you'll immediately see the benefits of Places over the approach you are using (which is not bad: I used it succesfully for a long time. Places do the same, but better :-)) Regards Lorenzo On Apr 3, 5:58 pm, Kostya Kulagin <kkula...@gmail.com> wrote: > 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.
