It's about optimization, I guess. If you just have a shallow Place object (say it only knows an ID) and always fetch the data you need, that means more calls.
If you let the Place object contain a lot more data, you still have to code for when it doesn't (eg., when the user navigates directly to a URL or does a right-click -> Open in new tab...). I was just curious if there's a preferred pattern here. On Thu, May 17, 2012 at 10:31 AM, Thomas Broyer <[email protected]> wrote: > > > On Thursday, May 17, 2012 2:56:40 PM UTC+2, Shaun Tarves wrote: >> >> Sorry, the alternative below would be to have the URL contain enough >> information about the new "place" (such as an ID if that's sufficient to >> get all the data we need) and then always populate from scratch. I would >> call that a shallow place - it doesn't contain all the data we need, but it >> contains enough data to go fetch it. > > > How is that different from the other suggestion ("set an href using the > placeHistoryMapper"), besides letting the browser do the navigation rather > than using preventDefault and calling PlaceController#goTo yourself? (that > last bit is actually mostly an "optimization" here) > > -- > 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/-/9tdo2nSwBPUJ. > > 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. > -- 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.
