GWT Actions and Location Links

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

For example, I have a ContactView with a contact table and the corresponding ContactActivity / Place classes. If I want to edit a contact, I click on the row of the table and go to ContactEditorPlace. How does ContactEditorView get a contact for editing?

The examples that I saw seem to indicate that they do not pass references to the actual objects in place, but instead they are faced with the problem of passing a string or identifier (for example, a cost pattern). Is there a reason for this other than simple tokenization? Is there a reason the link should not be in place?

If an object reference is not specified in the ContactEditorPlace constructor, then how does it get into ContactEditorActivity? This can be done using EventBus, but this would be a large number of templates for passing one link to one action.

I would notice that I am not using RequestFactory.

+7
source share
3 answers

To my mind:

There is no problem with passing object references in the place constructor. This way, you can easily transfer the Contact link by clicking on the line you want to change.

However, you probably should not use this object as a token. I think that it is best to use its id, and then extract the object from the identifier during de-occlusion and pass it to the constructor.

As for the Expenses example, I believe this because they use Request Factory, which has these Entity Locators that make it easy to fetch entities based on their identifiers.

+5
source

If you want to decouple the places, you can create a custom event that encapsulates your object, and then pass that event through the event bus.

Update:

Support for history / places is done using fragment identifiers (this is an official term, Google calls them history or place markers). Places are created by parsing FI (tokenization). You can format FI as you like, but the limitation is that they are strings. The FI format can be any (for example, # place / subplace: arg1: arg2). This is the task of your tokenizer to analyze FI and create a Place.

In your case, FI could be #contactedit: id. Thus, your tokenizer will analyze this token by creating a ContactEditorPlace that contains the identifier of the contact to edit.

+2
source

The place is also intended to indicate a history token. In this context, the values โ€‹โ€‹in the Place object become part of the application URL. This means that the user can put the URL into the browser at any time, and the Place object will be restored from that URL. When you pass a link to an object, that object does not exist when the user simply passes the URL. I always use as a general rule that values โ€‹โ€‹placed in a Place object should only be used to uniquely identify or recreate a particular application state, and no values โ€‹โ€‹simply because passing a value through place is easy.

In this case, you can transfer the object identifier to the "Field" field and get the object from some cache that you store in your application (which goes to the server if it is not in the cache) or directly retrieves the object from the server.

+1
source

All Articles