GWT - MVP

The kinds of changes to Activities and Places we're contemplating for future versions of GWT are primarily along the lines of using annotations and generators to automate the creation of PlaceTokenizers and ActivityMappers, for example. We're not talking about wholesale replacement, as we strive for API backward compatibility with each release.

How I understand things, a display region is a dynamic part of a webpage; Depending on the place you're at, a display region is populated with a specific activity. A activity manager is the manager of a display region and decides the right activity to show up for a given display region when a certain page is showing. So, in terms of your question : a display region can be a dynamic menu, a sidebar, a logout/login link.... not the entire group. An example page with menu displayregion, maincontent displayregion, sidebar displayregion example page #ContactDetailsPage:FooBar +> sidebar display region will be instructed by the sidebar- activitymanager to start the activity GrandChildrenActivity (display grandchildren in side bar) +> maincontact display region will be instructed by the maincontentarea-activitymanager to start the activity ContactDetailsActivity (display contact details in main content area) +> menu display region will be instructed by the menu-activitymanager to start the activity MenuActivity (show the menu) example page #Login +> sidebar display region will be instructed by the sidebar- activitymanager to display nothing (NULL) +> maincontact display region will be instructed by the maincontentarea-activitymanager to start the activity LoginActivity (display login page) +> menu display region will be instructed by the menu-activitymanager to start the activity WelcomeActivity (show a welcome msg) etc etc.

places and activities are orthogonal to each other a webpage consists of many display regions every display region is managed by a activity manager when a place change occurs, the activity managers are notified and they decide the activity to live inside the display region

Actually HelloMVP is a really confusing example, because - the activities are called HelloActivity and GoodbyeActivity - the places are called HelloPlace and GoodbyePlace but the activities and places are orthogonal to each other. That doesn't help to get a clearer understanding.

* I notice that you're injecting instances of your activities into your activity mapper. Activities are meant to be fairly lightweight objects, as opposed to the views that represent them, so they don't need to be singletons (which they effectively are since you have a single app with a single injected activity mapper). It's probably not necessarily a problem unless your activities have state associated with them (such as the entity that the user is currently working with), which you have to be careful to clear out between uses with different data. The same can be said about places.

My understanding is that you only want a single area of the shell to be managed by one ActivityManager. So if you have an entire shell/layout with more than one area that changes, let's say a main content area as well as a context menu (If I have MainAppPlace and SettingsAppPlace and OtherAppPlace both of which extend MainAppPlace, and you want to show a different context menu for Place of type SettingsAppPlace and places of type OtherAppPlace) I would just have main Shell that has a SimplePanel for content and Simplepanel for context_menu I just use an ActivityManager to control one spot of the main layout. is this not right? do you want your activitymanager controlling more than one area??

How to navigate To navigate to a new Place in your application, call the goTo() method on your PlaceController. This is illustrated above in the goTo() method of HelloActivity. PlaceController warns the current Activity that it may be stopping (via a PlaceChangeRequest event) and once allowed, fires a PlaceChangeEvent with the new Place. The PlaceHistoryHandler listens for PlaceChangeEvents and updates the URL history token accordingly. The ActivityManager also listens for PlaceChangeEvents and uses your app's ActivityMapper to start the Activity associated with the new Place. Rather than using PlaceController.goTo(), you can also create a Hyperlink containing the history token for the new Place obtained by calling your PlaceHistoryMapper.getToken(). When the user navigates to a new URL (via hyperlink, back button, or bookmark), PlaceHistoryHandler catches the ValueChangeEvent from the History object and calls your app's PlaceHistoryMapper to turn the history token into its corresponding Place. It then calls PlaceController.goTo() with the new Place. What about apps with multiple panels in the same window whose state should all be saved together in a single URL? GWT 2.1 does not attempt to provide a generic implementation of a composite Place; however, your app could create a CompositePlace, CompositeActivity, and CompositePlace.Tokenizer classes that delegate to the constituent members. In this case, only the composite objects would need to be registered with your app's ActivityMapper and PlaceHistoryMapper.

although we can't map a 1-Many relationship between a Place and an Activity, you can in fact map multiple places to the same activity and differentiate between the place with multiple init() methods in the activity.

there's absolutely nothing in GWT proper related to MVP actually; I refuse to call Activities an "MVP framework", it has nothing to do with MVP in my opinion

try to disconnect activities from MVP: Activities don't force you to do MVP, and you'll use MVP beyond Activities.