Group items tagged

how does the PlaceChange Event gets fired?? As of 2.1M2, PlaceController still isn't bound to History, so only PlaceController#goTo will fire first a PlaceChangeRequestedEvent (which can be rejected) and then (if the first hasn't been rejected by listeners) a PlaceChangeEvent.

My application has several modules, and in each module, it may have different layout. Hence I have multiple level of Activity and in each module, I have an ActivityManager and ActivityMapper to create an appropriate Activity according to the Place or return null if not interested.  All the ActivityManagers are attached to a global Event bus.

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)

use the history and pass the information as parameters in the history token.

has a number of advantages provided the parameter is serializable (and small enough). For example, it could let the user bookmark the detail page of "Lady_Gaga". A bit trickier when the presenter is a dialog box, but totally doable.

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)

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.