GWT活动和场所-如何理解这个概念？

Question

Okay, Activities build on top of Places. Places are " just URLs ". But I am just not getting it how to use them properly..

There are no nested Activities " because YAGNI "; but how does it look like in this simple scenario:

1. Having a login page
2. Having an administration page that offers functionallity for
   • Add events to my company
   • Add items to my store

After a successful login the "main container" of the website is cleared and filled with the new content of the admin-activity. One thing that has to be changed here is the "display" of the ActivityMapper since now I got a navigation bar on the left side and a main-content Div on the right side.

I could just have a LoginActivity and an AdminActivity . That means I'd have urls like

/#LoginPlace:noParams
/#AdminPlace:eventManager
/#AdminPlace:itemManager

But that's silly imho because for real I would like to have something like this:

/#LoginPlace:noParams
/#AdminPlace:eventManager|storeId=1,langaugeId=2
/#AdminPlace:itemManager|storeId=1,langaugeId=2,page=0

But that would require my AdminActivity to break up the URL and look out for all this different types of URLs, right? What I mean is something like this:

private AdministrationActivity administrationActivity;

@Override
public Activity getActivity(Place place) {

    if (place instanceof LoginPlace) {
        return new LoginActivity((LoginPlace) place);
    } else if (place instanceof AdministrationPlace) {
        if(this.adminActivity== null) {
            this.adminActivity= new AdministrationActivity((AdministrationPlace) place);
        } else {
            this.adminActivity.updateMainContent(((AdministrationPlace) place).getUrl());
        }
        return this.adminActivity;
    }

    return null;
}

Where now adminActivity.updateMainContent() will have to do the parsing for all places in order to display the correct content.

This would be the solution:

/#LoginPlace:noParams
/#EventManagerPlace:storeId=1,langaugeId=2
/#ItemManagerPlace:storeId=1,langaugeId=2,page=0

But (!) now I need an activity for each place, right? And I am just not sure if there are equally as many places as there are activities. I thought that one activity can navigate to different places.

So how are Places and Activities supposed to used?

Answer 1

The first questions you have to ask yourself is "where will the user possibly go?". As I understand it, you at a minimum have:

• list of events, with possible filter/selection criteria and paging attributes
• list of items, with possible filter/selection criteria and paging attributes

Maybe you'll also have places like "details of an event" (maybe even split between read-only details and editable details, if the user will switch between both states; if the state depends on who the user is, then this is IMO the same place, and actions the user can do are different), "details of an item", "form to add an event", "form to add an item".

To me, login is a cross-cutting feature, it's not something the user comes to doing in your app (it's not a business use-case, not an "activity" that's part of the user's job). You can still choose to use a place and activity for login though; so let's add that to the list: "login form" (definitely not how I'd do it, but that's another story).

Now you can choose how you want to represent those places as GWT Place objects: you can have one Place subclass with a property telling you which exact "place" you're on (basically what your AdminPlace:eventManager token suggests), or one Place subclass per "place" (what your EventManagerPlace token suggests). This is entirely independent of whether you'll have one or several activities.

The next question is about the various areas of the screen, that'll map to ActivityManager s: what parts of the screen do change when navigating? Maybe they do not all change at the same time / under the same conditions.
So for example, should your navigation bar be within the activity or not? If you can put it outside (because it's reused), do it. It actually need not even be an activity if it's always the same (modulo the selected item). In any case, it's probably a good idea to make it a singleton (or similar) and listening to PlaceChangeEvent s to select the appropriate item (not necessarily a "singleton", but at least not recreated on each navigation). The advantage of putting the navigation bar outside the activities is that if you finally decide to have it vertical rather than horizontal (or the other way around), and/or collapsible, you won't have to change your activities (separation of concern). If you ever have to build a mobile app, you could even have a "menu" place on that app that displays the navigation bar full-page and swaps it for the other activities when navigating.

So we now have 2 display regions , ie 2 ActivityManager s, and their respective ActivityMapper s. Or maybe just one display region for the "main content", and the navigation bar is not an Activity. The next step is to determine exactly what changes and when; ie when I go to place X, I need to have that thing in that area, and that other thing in that one; those "things" are your activities.

The key to "model" your Activities is to think about the things the user does (activities) and focus on one of them. But Activities are also tied to how the user interacts with the application, and the navigation (eg when adding an item, does the form appears in a popup above the list, or replaces the list); so if you want to really completely separate concerns, you'd probably create some object to manage the list of events/items and have a really thin Activity that only instantiates and manages that object. That's probably over-engineered as a starting point though, and it'll be relatively easy to factor the thing out of the Activity later if you feel it's needed.
I like (and that's basically how the feature has been designed) to have disposable activities. In my ActivityMapper , everything from the Place that the Activity needs to know is passed to its constructor; the Activity doesn't have to know the current place (or listen to place changes), and is not "mutated" by the ActivityMapper . There can of course be exceptions to the rule, for various reasons. If you need to share state between "places" for a given activity (eg data caches, etc.), you don't necessarily have to reuse it, you can share the state via shared stateful objects and keep the activity mostly stateless.
Anyway, your idea of a big AdminActivity that itself swaps a big part of its content depending on the current place is akin to nesting.

In the end, there's no one-size-fits-all, and you'll have to try and pick the strategy⋅ies that best fit your needs.

Last, but not least, don't design your place with a generic getUrl() that needs to be parsed ; parse everything in your PlaceTokenizer s; nothing else than the tokenizers need to know how the place will look like in your URL (and you're not even forced to use a PlaceHistoryHandler to begin with, so your places might not even ever end up in the URL –your places won't be bookmarkable then and you won't be able to navigate in the app through the browser history)
The key concept is separation of concerns.

Answer 2

I'd suggest you probably do want one Activity per Place. There is generally a rough one to one relationship but they are split due to separation of concerns and so you can pass around a Place without an Activity.

Adding parameters is sadly not supported by standard GWT. We created our own simple one based on UrlBuilder.

There is a long standing issue for this https://code.google.com/p/google-web-toolkit/issues/detail?id=2422 (old issue tracker) which has other thoughts and links.

Once it is up and running it works really nicely. I like using strongly typed objects and goTo rather than sticking URLs together.