Re: GWT history handling library - give it a try

Hi!

Thanks for the response - personally I like critisism very much. Noone
perfect (this is about myself).

Comments inlined

> I tend to not "trust" projects that have an empty source repository and
> only provide downloads. I generally take it as a sign that the developer
> doesn't use a VCS, and so that the project is in bad shape; not really a
> sign of quality if you ask me. If there are other reasons, then please make
> them explicit.

Absolyutely correct and agree, however lib is so small that I've
decided skip this step. Anyways - you are right.

> Also, the MainIdea [1] wiki page starts with "Core GWT as far as I know
> does not support URL history handling", which is either plain wrong [2] or
> doesn't mean what I think it means (and without the ability to browse the
> source online, I really can't tell; and I won't take the time to download
> the source to evaluate the project).
>
> As for the general approach (from what I can read from the wiki pages), I
> don't think it really "works". Do you really want to save the open/close
> state of each tree item in the browser's history? Navigating the app would
> quickly become a nightmare. URLs are for navigation, not about application
> state. This is why the HTML5 History API provides a specific argument in
> pushState() to store some state independently of the URL: there are things
> that you want to keep around as long as the app is "running" but that don't
> need to be carried along in the URL if you bookmark it or copy/paste it to
> a mail or IM.
> As for combining the state of several components into the URL (as the YUI
> Library provides, for instance), that makes ugly URLs that don't carry any
> "real" meaning; not quite "Cool URIs" [3,4].
> URLs are for navigation, and GWT provides a cool way of handling it for
> quite some time now: Places [5] (and if you ask me, you should use
> Activities too, but that doesn't fit everyone, so feel free to use GWTP,
> Mvp4g or whatever)
>
Again good points, again thank you.
Places are intended to descibe set of components on page but not their
(components) state.
And though if you want to support back forward buttons in a browser
for example for paging.
What will you do? You'll probably append some parameter to URL to
indicate which page you are currently on?
What it mean? It means ou'll have to save scomponent state indeed.

> All of the above are just a "first impression" though, as I haven't looked
> at the code (and no, I'm not going to download it)
>

Thanks!

--
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.