GWT Activity & Places: Order matters

The GWT Activity and Places framework is a useful and common mechanism to use the browser history within your application allowing users to bookmark URLs and use the back button as a feature. To do so, it automatically updates the URL token when navigating to another place.

A simple scenario

Today, it’s quite usual to build a GWT application which requires authentication. So if the user goes to a bookmarked URL (e.g. myapp.com/#DashboardPlace:) and is not logged in, he needs to be redirected to the login form. This is typically realized as follows:

public abstract class AbstractSecuredActivity extends AbstractActivity {
    @Override
    public void start(AcceptsOneWidget panel, EventBus eventBus) {
        if (!clientFactory.getSessionContext().isAuthenticated()) {
            clientFactory.getPlaceController().goTo(new LoginPlace());
        } else {
            // ...
        }
    }
}

And of course, the URL token should be updated accordingly (e.g. myapp.com/#LoginPlace:).

Putting the Activity and Places framework parts together as documented the redirection will result in the following:

  • the login form is displayed in the browser
  • but the address bar shows myapp.com/#DashboardPlace:

How can this happen?

Technically, when going to an URL or another place a PlaceChangeEvent is fired which has two handlers:

In the szenario discribed above, the events are fired and handled in the following order:

  1. Going to the “myapp.com/#DashboardPlace:”-URL fires the PlaceChangeEvent for DashboardPlace.
  2. The ActivityManager handles the PlaceChangeEvent for DashboardPlace. Within the started Activity the PlaceChangeEvent for LoginPlace is fired.
  3. The ActivityManager handles the PlaceChangeEvent for LoginPlace. Within the started Activity the login form is displayed.
  4. The PlaceHistoryHandler handles the PlaceChangeEvent for LoginPlace. So the URL token is updated to “myapp.com/#LoginPlace:“.
  5. The PlaceHistoryHandler handles the PlaceChangeEvent for DashboardPlace. So the URL token is updated to “myapp.com/#DashboardPlace:“.

This is where order matters!

The behavior described above depends on the order in which the ActivityManager and the PlaceHistoryHandler are registered for the PlaceChangeEvent, what is done respectively within the highlighted method calls:

@Override
public final void onModuleLoad() {
    // ...
    ActivityMapper activityMapper = new AppActivityMapper(clientFactory);
    ActivityManager activityManager = new ActivityManager(activityMapper, eventBus);
    activityManager.setDisplay(appWidget);

    AppPlaceHistoryMapper historyMapper= GWT.create(AppPlaceHistoryMapper.class);
    PlaceHistoryHandler historyHandler = new PlaceHistoryHandler(historyMapper);
    historyHandler.register(placeController, eventBus, defaultPlace);
    // ...
}

So, if you change the order of these method calls, the events are handled as follows:

  1. Going to the “myapp.com/#DashboardPlace:”-URL fires the PlaceChangeEvent for DashboardPlace.
  2. The PlaceHistoryHandler handles the PlaceChangeEvent for DashboardPlace. So the URL token is updated to “myapp.com/#DashboardPlace:“.
  3. The ActivityManager handles the PlaceChangeEvent for DashboardPlace. Within the started Activity the PlaceChangeEvent for LoginPlace is fired.
  4. The PlaceHistoryHandler handles the PlaceChangeEvent for LoginPlace. So the URL token is updated to “myapp.com/#LoginPlace:“.
  5. The ActivityManager handles the PlaceChangeEvent for LoginPlace. Within the started Activity the login form is displayed.

After that the login form is displayed in the browser and the address bar shows myapp.com/#LoginPlace:. And this is exactly what we wanted.

Short URL for this post: http://wp.me/p4nxik-1ne
This entry was posted in Java Web Frameworks and tagged , , , , , . Bookmark the permalink.

One Response to GWT Activity & Places: Order matters

  1. Pingback: Links for March 29th through April 2nd

Leave a Reply