You're partly right in my opinion. What I exposed is (part of) a (siplified) "library" approach VS the typed, Place approach.
A Place is an Object Oriented representation of a client side URL, tied to your browser history, and offers you typed methods to have in an object oriented way all the parameters (from the URL) you need to have to restore your objects' state correctly, and to save them to an URL. To have an efficient serialization the recommended approach is to have a base Place with its tokenizer, i.e. one class handling serialization and deserialization from and to your URL, then extend it. It's just the matter to write a single serialization/deserialization class (or a library, if you prefer). The point is that all this comes in standard GWT, so looks like there's no need to develop a separate library to do exactly the same. regards Lorenzo On Apr 3, 11:58 am, Kostya Kulagin <[email protected]> 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 <[email protected]> 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 <[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.
