GWT Activities and Places passing references

How do you get an object from one Place to another?

For example, I have a ContactsView with a table of Contacts, and the corresponding ContactsActivity/Place classes. If I want to edit a contact, I click on the table row and go to the ContactEditorPlace. How does the ContactEditorView get the Contact to edit?

The examples I've seen seem to make a point of not passing actual object references in the Place, but instead they go to the trouble of passing a String or id (e.g., the Expenses sample). Is there any reason for this other than easy tokenization? Is there some reason a reference should not be in a Place?

If the object reference is not set in the constructor of the ContactEditorPlace, then how does it get to the ContactEditorActivity? This could be done with the EventBus, but that would be a lot of boilerplate to pass a single reference to a single activity开发者_运维技巧.

I would remark that I am not using RequestFactory.

In my opinion :

There's no problem passing object references in the place's constructor. That way you can easily pass the Contact reference when clicking on the row you want to edit.

However it's probably not a good idea to use that whole object as the token. I think it's best to use it's id and then fetch the object from the id when detokenizing and pass it to the constructor.

As far as the Expenses example, i believe it's because they use the Request Factory which has those Entity Locators that make it easy to fetch entities based on their ids.

If you want to have decoupled Places then you can create custom event encapsulating your object and then pass this event via event bus.

Update:

History/Places support is done with Fragment Identifiers (thats the official term, google calls them history or place tokens). Places are created by parsing FIs (tokenization). You can format FIs any way you like, but the limitation is that they are strings. The FI format can be anything (e.g. #place/subplace:arg1:arg2). It's the job of your tokenizer to parse the FI and create the Place.

In your case the FI could be #contactedit:id. So your tokenizer would parse this token creating ContactEditorPlace that contains the id of the contact to edit.

Place is designed to also represent a history token. In that context the values in a Place object become part of the application url. This means a user can put the url into the browser at any moment and a Place object is reconstructed from that url. When you would pass an object reference, this object doesn't exist when a user just passes a url. I always use as a general rule that values put in a Place object should just be used to uniquely identify or recreate a specific state of an application and no values just because passing a value via place is easy.

In this case you could pass the object's id in the Place and get object from some cache you keep in you application (which goes to the server if it's not in the cache) or directly fetch the object from the server.