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 [email protected].
To post to this group, send email to [email protected].
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.


Reply via email to