Re: Nested Views in MVP

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 composite views:

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 corresponding views. 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 their views from
a factory as in the HelloMVP example, this should not be noticeable,
as views obtained 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 <drgenejones@gmail.com> wrote:
> Hi,
>
> I have been reading the excellent article at:
> http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html
>
> And love the new built in objects that facilitate the MVP design
> paradigm.  My initial thought is great but how does this system cope
> with Nested Views or 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 google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

--
David Chandler
Developer Programs Engineer, Google Web Toolkit
http://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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.