Thanks for your perspective. Passing an object ID around certainly seems better than serializing the whole data object in the tokenizer, especially considering that the data object can be cached. I read somewhere on a blog yesterday where someone chose to implement the presenter in a separate object. The presenter would have access to the model and be available to the activity from the global client factory object. I'll have to get more experience before I can properly evaluate this architectural variation. Initially I will keep the presenter and activity together because the simplicity is attractive.
Regards Craig On Tuesday, February 26, 2013 5:33:43 AM UTC-4, Jens wrote: > > Its just a matter of taste. > > I guess most people only store the database Id inside the place and then > fetch the data in the activity. If you have multiple activities active at > the same time you may build a thin layer between your activity and RPC > mechanism so that only one request is done for a given database id even if > all active activities request it at the same time. > > Sometimes people fetch the data once and then want to pass it around to > different activities so they dont need to load it again. In that case you > would add the database id and the data to the place and then first check if > data is available and if not fetch it by using the id. > This would be a similar situation to your DTO. The reason why you would > have both id and data itself in the place is that only the id is used in > the Tokenizer for the place URL. You most likely don't want all DTO data > serialized in the URL. Its the same as not having the whole UI state > serialized in the URL. Only choose the most important parts that gives a > good result when accessing the URL directly. All other UI state could be > saved to local sessionStorage (e.g. scrollbar positions, specific textbox > contents, whatever). > Alternatively you could also add a thin caching mechanism so you don't > need to put data into the place. Just "refetch" the data by id from the > local cache. > > I treat the place URL as an ordinary URL for navigation so most times they > simply look like: <menuitem>/<optional submenuitem>/<database id of data > needed>/<coarse UI state like a Tab or a category that should be selected > by default>. Something like #/employees/1/address would go to the employees > screen, cause the activity to load employe with ID 1 and then show the > address tab/category in the UI. Everything else would be stored in local > sessionStorage. > > Personally I think the only URLs that could be very long are URLs that > represent a search query with lots of search criteria and you want that > search query to be bookmarkable. Everything else should be fairly short, > but your mileage may vary. > > -- J. > > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
