GWT: Granularity of Places and ActivityMappers

StackOverflow https://stackoverflow.com/questions/13103795

Question

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.

Was it helpful?

Solution

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:

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top