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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment