GWT Activities and Places passing references

Question

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.

Knight

Answer 1

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.

Critic

Thanks jonasr. Of course the object itself is not the token. In my case the object has an id that could be used as a token. But tokenizing is another issue. I suppose I'm asking if there is a design drawback to having a Place have state, but since the Javadoc for Place expects it to implement equals() I'm thinking Place can be expected to have object references in it. – Knight

Putting an object in your Place rather than just its ID does not make it "have state". The only drawback I can see is that your code that "processes" the place (your ContactEditorActivity) will have to cater for the case where the object is just not there (because the Place has been reconstructed from an history token, for instance), which leads to more complex code. I think the overall idea is rather to pass IDs around but have some caching mechanism in place so you can take the object back from its ID without necessarily contacting the server. – Columbus

Answer 2

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.

Cyclopentane

Thanks, Peter, but I do not want to decouple. I want to couple (yeah, yeah, "that's what she said"). The Contact list and the Contact editor are closely bound. If my editor view was just a few fields I could skip making a Place and put a reference for the Contact in a ContactEditorView constructor and show the editor in a DialogBox, but it is large for a popup and needs a screen. Putting a reference in a constructor is a few lines that makes the event bus – Knight

I was going to say Putting a reference in a constructor is a few lines compared to an event bus solution that requires at least another class---it should not be that hard. – Knight

Answer 3

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.

Zhang

Thanks Hilbrand. I understand that Place is used to create urls for navigation, and to enable reconstruction of state from a url. And the largely undocumented feeling that it should do that in a minimal way is why I'm wondering if using Place for a reference was a bad idea. But note that I already have a cache for the data I want: it's called ContactList. Your solution amounts to downloading the same data again, or to writing a client side persistence layer. – Knight