--3) If an application does not use Places and Activities - I should think what to do in that case.
I just stepped into reworking an application that used a custom history mapper (developed before places were available) to a Places design, so here's what I found. If you don't use Places, you'll go and use GWT native history support (https://developers.google.com/web-toolkit/doc/latest/ DevGuideCodingBasicsHistory) building an HistoryToken based on your object properties, and viceversa. This is a sample from my own code private Map<String, String> parseHistoryToken(String token){ Map<String, String> properties = new HashMap<String, String>(); if (!token.startsWith(MAIN_LBL + "/")) return properties; String toParse = token.substring(MAIN_LBL.length() + 1, token.length()); String[] propList = toParse.split("/"); for (int i = 0; i < propList.length; i++){ String property = propList[i]; if (property.length() < 3)// il controllo serve perché il primo // split ritorna un array con una // stringa vuota e non un array vuoto continue; String[] values = property.split("="); //nella history il valore null è salvato come stringa == "null" String value = (values[1].equals("null")) ? null : values[1]; properties.put(values[0], value); } return properties; } It will cut a history token like #home/prop1=123/prop2=zaq into a map like <prop1, 123>, <prop2, zaq>, and map.get("prop1") will return a String "123". This is *exactly* what a PlaceTokenizer and a PlaceHistoryMapper will do, except for the fact that you can then access your HistoryToken properties in a type safe way (i.e. you'll call some methods on your Place). You'll write a PlaceTokenizer to build sort of a CustomPlace, and call ( (CustomPlace) PlaceController.getWhere()).getProp1(). The *huge* difference is that getProp1() can return a type (String, Integer, CustomObject etc.) and once you defined a tokenizer from your place to the URL and viceversa this will work correctly. This means getPlace1() will return the Integer 123, not a String, and if you build a "bad" URL you'll get (and handle) a meaningful exception. If you try to dig into the Places tutorial Thomas Broyer linked before you'll find out that this is the behavior you get. So if you don't use places, but want a good history support, the best way is, er, go for Places :-) You don't need Activities for history support, using Places, a PlaceHistoryMapper and listening to PlaceChangeEvent will do a top class history support by themselves. Again, the article mentioned above is a clear and helpful starting point, just try to code a simple use case. Regards Lorenzo On Apr 2, 10:33 am, 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.
