Hello David, looking at your example: .... > SimplePanel westWidget = new SimplePanel(); ....
> westActivityManager.setDisplay(westPanel); is this a typo ? should have been westActivityManager.setDisplay( westWidget ); ? thank you On Oct 29, 6:57 am, David Chandler <[email protected]> wrote: > Gene, > > Thank you for your thoughtful questions. As you have observed, > Activities and Places do not directly support nesting, but there are a > couple different ways you can implement compositeviews: > > 1) An ActivityManager is responsible for swapping activities within > one container widget; however, you can have multiple ActivityManagers, > each with its own ActivityMapper and container widget. Suppose your > application's main widget is a DockPanel with a westPanel and > eastPanel. You would then have something like this: > > DockLayoutPanel dockLayoutPanel = new DockLayoutPanel(Unit.PCT); > SimplePanel westWidget = new SimplePanel(); > SimplePanel eastWidget = new SimplePanel(); > > WestActivityMapper westActivityMapper = new WestActivityMapper(); > WestActivityManager westActivityManager = new > WestActivityManager(westActivityMapper, eventBus); > westActivityManager.setDisplay(westPanel); > > EastActivityMapper EastActivityMapper = new EastActivityMapper(); > EastActivityManager eastActivityManager = new > EastActivityManager(eastActivityMapper, eventBus); > EastActivityManager.setDisplay(eastPanel); > > dockLayoutPanel.addWest(westWidget, 50); > dockLayoutPanel.addEast(eastWidget, 50); > RootLayoutPanel.get().add(dockLayoutPanel); > > PlaceMapper and PlaceHistoryHandler would be initialized the same as > in the HelloMVP example. > > In this design, the WestActivity could call > placeController.goTo(detailPlace), where DetailPlace is mapped only in > the EastActivityMapper so the westPanel won't change. Alternatively, > the EastActivityMapper and WestActivityMapper can each map the same > Place to a different Activity, in which case the Activities in both > panels will change. This is one way to implement a composite Place. > > 2) There is not necessarily a 1:1 correspondence between Activities > and presenters. Your Activity might instantiate multiple presenters > and correspondingviews. When the Place changes, the whole composite > Activity will be swapped out, and, as you pointed out, this will > result in setWidget() being called on the ActivityManager's container > widget. However, if activities and presenters obtain theirviewsfrom > a factory as in the HelloMVP example, this should not be noticeable, > asviewsobtained from the factory would not be reconstructed. > > Does that help? We welcome community feedback on what works best. > > /dmc > > > > On Fri, Oct 29, 2010 at 12:52 AM, DrG <[email protected]> wrote: > > Hi, > > > I have been reading the excellent article at: > >http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAnd... > > > And love the new built in objects that facilitate the MVP design > > paradigm. My initial thought is great but how does this system cope > > withNestedViewsor Dock Panel style layouts where various elements > > can be clicked and the widget that changes isn't necessarily always > > the center one? > > > Looking at the example code given for HelloMVP it looks like when you > > go to a new Place when the Activity is started by calling the start > > method a widget is passed in that is the containerWidget or host for > > that presenter: > > > �...@override > > public void start(AcceptsOneWidget containerWidget, EventBus > > eventBus) { > > GoodbyeView goodbyeView = clientFactory.getGoodbyeView(); > > goodbyeView.setName(name); > > containerWidget.setWidget(goodbyeView.asWidget()); > > } > > > Looking at the setup code from the onModuleLoad, a root SimplePanel is > > added to the activity manager: > > > activityManager.setDisplay(appWidget); > > > This widget is then passed to the start method each time a new place > > is revealed. Thus causing a screen refresh? each time a new place is > > revealed. > > > How would you handle a scenario that has a Left hand menu (like gmail) > > and a main container. Where clicking options in the LHS initiates a > > new widget to be displayed in the center. Using the current logic it > > looks like the whole screen is refreshed to show the newly selected > > menu option and the center widget. Perhaps it does, and perhaps this > > is ok, but it sounds hacky. > > > For example it would be nice if clicking a center widget not only > > indicated what place to reveal but where that place/widget should be > > revealed? > > > I am sure this scenario is very common and it may have a lot to do > > with my naivety with this new methodology. If anyone has any > > pointers, opinions or examples on this it would be greatly > > appreciated. > > > Cheers > > Gene > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/google-web-toolkit?hl=en. > > -- > David Chandler > Developer Programs Engineer, Google Web > Toolkithttp://googlewebtoolkit.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
