5

I'm finally starting to "get" GWT. At any time, a PlaceChangeEvent can be fired on the app's EventBus like so:

History.newItem("token-for-some-new-place");

This adds the event to the bus, whereby a registered ActivityManager scoops it up and consults its internal ActivityMapper to give it the Activity associated with the PlaceChangeEvent's Place.

The Activity (similar to a presenter or controller object from MVP/MVC) then obtains any data that is needed (via RPC calls to the server) and executes any business logic and configures the final view (typically a Composite of some sort) to display.

As long as we're talking about a super-simple GWT app that only has one display region on its host page, then like I said, I "get" it.

Where I am choking now is what happens when you have an app that contains multiple display regions (areas that can be updated asynchronously from one another).

So I ask:

  1. How granular are ActivityMappers supposed to be? Is there just one app-wide AppActivityMapper that maps all Places to all Activityies, or should there be some sort of ActivityMapper hierarchy/decomposition, where you have multiple mappers? (And if your answer to this is something along the lines of "this depends on the needs of your application" then please explain what requirements/needs drive the appropriate level of granularity!)
  2. If a Place represents a URL token in your app (for the sake of making the Place a bookmarkable state), then what happens when you have a more complex app that has multiple display regions (D1, D2, D3). How does one URL token (i.e. http://myapp.com/#token-for-some-new-place) map to D1, D2 and D3? Wouldn't that mean ActivityMapper#getActivity would have to be capable of returning a list of activities (List<Activity>) whose start(AcceptsOneWidget, EventBus) methods would all get callled?

Thanks for any help here - code examples always rock.

1 Answers1

5

A Place represents, well, a place. It answers the existential questions of where did I come from?, where am I? and where am I going to?.

For a given place, the screen that's displayed to the user can be complex, and divided into a bunch of display regions. Each one is governed by an ActivityManager, which asks an ActivityMapper which Activity to use for a given place, making everything loosely coupled (activities don't (have to) know where they're being used, for which place, which other activities are running concurrently, etc.)

So, you won't have a mapper that'd return a list of activities, but a list of mappers each returning one activity.

See:

Thomas Broyer
  • 64,353
  • 7
  • 91
  • 164
  • Thanks @Thomas Broyer (+1) - however, here you're saying that a `Place` exists at the page/screen level, whereas `ActivityManagers` and `ActivityMappers` exist at the display region level (where a *screen* consists of 1+ *display regions*). **But how is this possible?** If display regions D1, D2 and D3 can each exist in 5 bookmarkable states, and they all belong to the same screen, then the screen can exist in 5^3 = 125 bookmarkable states! How can a single (screen-level) Place represent 125 states! –  Oct 28 '12 at 16:23
  • 2
    Not sure I understand what you're saying here, but my tentative answer would be: all display regions change at the same time (that doesn't mean they *have* to change though, you can have some of them display the same activity as for another place, but still thay've been asked for the activity to display for the current place). Here on StackOverflow, the menu bar (with the logo), the "tagged" section at the top-right, the "community bulletin", the ad and the "related" below, and finally the main area with the question and answers; 1 URL (place) dictates what appears in each area (activities). – Thomas Broyer Oct 29 '12 at 09:39
  • Ahhh...so to use my example above, if display regions D1, D2 and D3 can each exist in 5 bookmarkable states, then given a URL of, say, `http://myapp.com/#some-state`, they will each have their own, independent mappers that know what `Activity` to show. That makes sense, thanks! –  Oct 29 '12 at 10:59