Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'd go with History tokens. It's the standard way of handling such situations. I don't understand though, what you mean by "It is hard to produce a human friendly URL with history tokens" - they seem pretty human friendly to me :) And if you use servlets for handling urls, I think that would cause the whole page to be reloaded - something which I think you'd rather want to avoid.</p> <blockquote> <p>Second, I'm using gwt-presenter and this approach would mean that we need to support subplaces in one token, which I'd rather avoid.</p> </blockquote> <p>If you are not satisfied with gwt-presenter (like I was :)), roll out your own classes to help with MVP - it's really easy (you can start from scratch or modify the gwt-presenter classes) and you'll get a solution suited to your needs. I did precisely that, because gwt-presenter seemed to "complicated"/complex to me - to generic, when all I needed was a subset of what it offered (or try to offer).</p> <p>As for the multiple modules idea - it's a good one, but I'd recommend using <a href="http://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html" rel="nofollow noreferrer">Code Splitting</a> - this type of situation (pages/apps that can be divided into "standalone" modules/blocks) is just what it's meant to be used for, plus you bootstrap your application only once, so no extra code downloaded when switching between pages. <em>Plus</em>, it should be easier to share state that way (via event bus, for example).</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COI agree that history tokens seems like the intuitive choice, but I'm still not convinced that it is optimal :-). What I mean with non human friendly URLs is that GWT history prefixes the token with a # (which most users won't remember). Also, since users typically expect an url to consist of / only, I would need to use / as both place and parameter separator, which is hard to maintain. Or am I missing something related to history handling here? I do agree that code splitting would make sense with this solution.
      singulars
    2. COThe whole point of users "remembering" the url doesn't quite get to me (but then again, I don't know what sort of page you are working on and who the users might be) - I don't think anyone tries to remember urls nowadays, not when there are sites like del.icio.us, people bookmark sites they visit often. Besides, the hash/# in address is not something Google came up with, it's the standard way all browsers use and support, usually referring to an `id` of a DOM element, but in case of web application - to its state. Gmail uses it, as does an increasing number of web sites.
      singulars
    3. COYou might be right. Perhaps I'm putting too much effort into the whole "friendly" URL thing. For Gmail, it doesn't make any difference since you always access the main site. In my case, users will in 90% of the cases go directly to a project page, which is why I think it would be nice if it was a natural URL like http://www.site.com/project/theproject instead of something like http://www.site.com/#page=project&name=theproject. I will re-think this approach a bit :-). Thanks for your input.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload