On Tuesday, April 3, 2012 5:58:54 PM UTC+2, Kostya Kulagin wrote: > > 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 unfortunately (or fortunately) not how the Web works. Not that it's impossible to do it (on the contrary), just that in the end it does more harm than good to your users; and the *user* experience matters more than the developer's one. I strongly suggest that you approach the problem from the other side: you "name" things (give them URLs, and use a Place –or whatever, but Place exists so why not use it?– to make a type-safe representation) and then you make your app reflect that thing. Going to a new place will translate into changing its internal state for a given component. Actions within a component do not necessarily have to be *replaced* by place changes, you can do the change in the internal state *and* go to a new place (and as I already said, you can factor that out using events of a "navigator" abstraction if you don't want your component to deal with places); the place change will go back to your component, but it'll be a no-op as the internal state already matches the one to "attain" given the new place. Every state that's not in the "name" of the thing should IMO either not be persisted, or simply stored in localStorage or similar. The browser's history is tightly bound to this, and this is the guide to draw the line between "named things" and the other states: for instance, going to the second "page" of a paged list/table should in most cases be reflected in the URL and the browser's history; which items are expanded/collapsed in a tree, which field has the focus, or which row has the "keyboard highlight" in a list/table should not. On Tuesday, April 3, 2012 5:58:54 PM UTC+2, Kostya Kulagin 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 view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Cm88BRZxuBsJ. 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.
