GWT MVP - maintaining multiple displays that are separate of one another
Asked Answered
B

1

7

I have a GWT App and I am using GWT MVP with Places / Activities.

My application layout is something like

MENU | CONTENT

The Menu and the Content displays will change dynamically and one changes separately from the other. What I mean by this is that when the Content display changes I do not want to have to update the Menu display and vice versa. Both displays need to be able to respond to PlaceChangeEvents and update themselves when these occur. The problem is that each display should only update in response to certain PlaceChangeEvents, ignoring PlaceChangeEvents that are directed at the other display. However this does not work using the 'standard' GWT MVP pattern because even when each display has it's own ActivityManager they will automatically pick up ALL PlaceChangeEvents because there is a single PlaceController listening on a single EventBus. The only way I can see to do this is by having two EventBus's and two PlaceControllers - one for the Menu and one for the Content. So my question is whether this is a good solution or is there a simpler/better way that I am missing? One problem with this solution is that the PlaceHistoryHandler can only be registered with one of the EventBus's.

Buonarroti answered 4/5, 2011 at 6:55 Comment(0)
S
5

Place changes are actually controlled by ActivityMappers. They get a Place and return the corresponding Activity. This is where you control how Places are mapped to Activities:

  1. You need to create two ActivityMappers (MenuActivityMapper, ContentActivityMapper) and then instantiate two ActivityManagers each with it's own ActivityMappers. Then for each ActivityManager you call setDisplay(AcceptsOneWidget display) where for each you pass in an area (display) where it will show it's content.

  2. For menu you will probably only use one Activity, since it's available in all Places. So MenuActivityMapper.getActivity() will always return the same instance of the MenuActivity. To enable MenuActivity to still adapt it's look based on place changes, MenuActivity should listen to PlaceChangeEvents.

Soak answered 4/5, 2011 at 12:41 Comment(5)
Hi Peter, Thanks for the response. This is the solution that I started with but here is my problem with it: When a PlaceChangeEvent occurs that should change only the Content display the MenuActivityMapper is still going to respond to that event. I tried just returning null from the MenuActivityMapper when the PlaceChangeEvent was one that it wasn't interested in but this just resulted in the Menu display being blank. Continued next comment...Buonarroti
I could just return the same MenuActivity for all PlaceChangeEvents as you suggest but that will mean running through all the logic for instantiating the Menu display (in my case this will be quite expensive) each time the content changes (which will happen frequently) and I would like to avoid this. Do you have any comment regarding using two event buses to separate the event listening for each display?Buonarroti
Not true. If you always return the same instance of MenuActivity (singleton field inside MenuActivityMapper), then ActivityManager will not call start() on it: google.com/codesearch/p?hl=en#A1edwVHBClQ/user/src/com/google/…Soak
Why would you want to have two event busses? How will you decide on which you will fire events? You can have one event bus and only listen to events you are interested to.Soak
Thanks Peter, the fact the ActivityManager will not call start() was the missing piece of the puzzle for me. CheersBuonarroti

© 2022 - 2024 — McMap. All rights reserved.