Group items tagged

An activity in GWT 2.1 is analogous to a presenter in MVP terminology. It contains no Widgets or UI code. Activities are started and stopped by an ActivityManager associated with a container Widget. A powerful new feature in GWT 2.1 is that an Activity can automatically display a warning confirmation when the Activity is about to be stopped (such as when the user navigates to a new Place). In addition, the ActivityManager warns the user before the window is about to be closed.

A place in GWT 2.1 is a Java object representing a particular state of the UI. A Place can be converted to and from a URL history token (see GWT's History object) by defining a PlaceTokenizer for each Place, and the PlaceHistoryHandler automatically updates the browser URL corresponding to each Place in your app.

A key concept of MVP development is that a view is defined by an interface.

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.

he generally adopted way of doing things in GWT is to have custom events go through the event bus. In this case, you're talking about "navigation", so maybe the concept of "place" would be better than "just" some custom event. I encourage you to look at gwt-platform, gwt- presenter and other MVP frameworks for GWT, and/or look at the Activity concept from the upcoming GWT 2.1. Using actvities, you'd have an ActivityManager managing your "center". The tree would use the PlaceController.goTo to navigate to a new "place". An ActivityMapper (that you passed to the ActivityManager in the constructor) would map the place to an Activity (a presenter), and the ActivityManager will manage the current Activity for the display it manages, i.e.it will stop() the current activity if its ok (willStop returns true) and then only start the new Activity, which will call the Display back to show its view. The tree would probably also listen to PlaceChangeEvent on the event bus to update the selected item depending on the current place (in case some other component calls the PlaceController.goTo)

he generally adopted way of doing things in GWT is to have custom events go through the event bus. In this case, you're talking about "navigation", so maybe the concept of "place" would be better than "just" some custom event. I encourage you to look at gwt-platform, gwt- presenter and other MVP frameworks for GWT, and/or look at the Activity concept from the upcoming GWT 2.1.

Using actvities, you'd have an ActivityManager managing your "center". The tree would use the PlaceController.goTo to navigate to a new "place". An ActivityMapper (that you passed to the ActivityManager in the constructor) would map the place to an Activity (a presenter), and the ActivityManager will manage the current Activity for the display it manages, i.e.it will stop() the current activity if its ok (willStop returns true) and then only start the new Activity, which will call the Display back to show its view. The tree would probably also listen to PlaceChangeEvent on the event bus to update the selected item depending on the current place (in case some other component calls the PlaceController.goTo)

your ChatBoxPresenter isn't related to a "place", i.e. it's "awoken" based on a "business event", not a navigation event; and in other words, it's not an Activity: case made. Activities (ActivityManager) is limited in scope to reacting to place changes and navigation (not that you couldn't use the Activity "contract" in other scenarios, such as your "chat box", but the ActivityManager wouldn't be the right tool for the job, you'd have to find/write another "activity manager" for your different use case). In other words: GWT 2.1 Activities won't replace GWTP as a whole (and I believe, as I already said in the past, that it's not its goal either).

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.

I think the overall idea of activities is that they are short-lived instances, so they're effectively "lazily created" (actually, a new instance is created each time one is needed) and they don't need to be "awoken" because if they're not currently in use they're already "dead" and garbage collected. The ActivityManager (actually its associated ActivityMapper) will decide whether a particular activity is needed (and then instantiate it, possibly going through a GWT.runAsync for code splitting); the activity will listen to events its interested in *during its lifetime* (e.g. whether some object has changed or has been added or deleted, so it can update its view); but when it's done (stopped or cancelled), it's simply thrown away (the event bus passed to the start() method is a ResettableEventBus so all handlers have been automatically unregistered for you, which as a side effect allows the activity to be garbage collected). This is the (AIUI) intended use, but nothing forces you to write such short-lived instances: you can very well use singletons, but then you'll have the additional task of maintaining state between "runs" (start/stop or start/cancel), in which case your activity can listen to events from the event bus after being stopped/cancelled (just use the "real" event bus instead of the ResettableEventBus passed to the start() method); but it won't "ask to be revealed": navigation is handled at another layer, triggered on the PlaceController and handled by ActivityManagers.

Activities are more tied to the concept of Places than of MVP, i.e. navigation and user experience rather than code structure ("developer experience").

I think the overall idea of activities is that they are short-lived instances, so they're effectively "lazily created" (actually, a new instance is created each time one is needed) and they don't need to be "awoken" because if they're not currently in use they're already "dead" and garbage collected. The ActivityManager (actually its associated ActivityMapper) will decide whether a particular activity is needed (and then instantiate it, possibly going through a GWT.runAsync for code splitting); the activity will listen to events its interested in *during its lifetime* (e.g. whether some object has changed or has been added or deleted, so it can update its view); but when it's done (stopped or cancelled), it's simply thrown away (the event bus passed to the start() method is a ResettableEventBus so all handlers have been automatically unregistered for you, which as a side effect allows the activity to be garbage collected). This is the (AIUI) intended use, but nothing forces you to write such short-lived instances: you can very well use singletons, but then you'll have the additional task of maintaining state between "runs" (start/stop or start/cancel), in which case your activity can listen to events from the event bus after being stopped/cancelled (just use the "real" event bus instead of the ResettableEventBus passed to the start() method); but it won't "ask to be revealed": navigation is handled at another layer, triggered on the PlaceController and handled by ActivityManagers.

In our app, in effect, each "parent presenter" also plays the role of "app controller"; but because we have the presenter/view dichotomy, the view exposes setSomeWidget(...) methods that the presenter calls; e.g. setHeader(...), setBody(...), setFooter(...).

> 3- what do you think of "presenter.go(container)" ? We do it the other way around: our presenters have a getView() method and the parent calls container.add((Widget) child.getView()). This is actually split between the presenter and the view, see above: view.setHeader(childPresenter.getView()) in the presenter, and containerWidget.add((Widget) child) in the view. The only "issue" with presenter.go(container) is that container must be a "simple" container, which means that when it's meant to be a dock (layout) panel, tab panel, or some other complex panel (or an absolute panel and you want to add with coordinates), you actually have to add a SimplePanel first and pass it as the "container" to the go() method. Otherwise, I can't see a problem with presenter.go(container).

navigation/ > history token inside multiple IF statements ? I'm using a very similar approach as the one in bikeshed: http://code.google.com/p/google-web-toolkit/source/browse/trunk/bikes...