1
votes

We have an application with multiple EntryPoints. Each EntryPoint contains an MVP configuration with their own PlaceHistoryHandler, PlaceHistoryMapper and PlaceController. Depending on the order that the history handlers were configured, the place treatment is overlapped. I think the problem is raised because the implementation of PlaceHistoryHandler invokes PlaceController.goTo(NOWHERE) when the PlaceHistoryMapper do not find the place, because this place is associated with the PlaceHistoryMapper of another EntryPoint. How I can solve this problem? It is right to use MVP with multiple EntryPoints?

Further info

Thomas, thanks for your clarifications. Our scenery is a server side OSGI application, where application modules are hot deployed and contains their own GWT views and EntryPoints. Our main client GWT application has a dynamic side menu, with hyperlinks pointing to tokens associated with the external EntryPoints having views rendered in a main region.

  SIDE MENU
      |
      V
  -------------------------------------------
  |  A1  |                                  |
  |------|                                  |
  |  A2  |                                  |
  |------|                                  |
  |  B1  |                                  |
  |------|         MAIN REGION              |
  |  B2  |                                  |
  |------|                                  |
  |  C1  |                                  |
  |------|                                  |
  |  C2  |                                  |
  -------------------------------------------

What is the right approach to solve this kind of application?

1
How did you manage to overlap them? What happens when you send a user from one entry point to another?Andrei Volgin
Short answer: don't do that, that won't work; long answer: groups.google.com/d/topic/google-web-toolkit/ct5ogmBmXrM/…Thomas Broyer

1 Answers

0
votes

You have two options:

(A)

Don't use PlaceController for the side menu. Make it a widget that contains links to places in your modules. You can include this widget in each module. When a menu item is clicked, the entire page reloads. This way browser history will work as expected.

(B)

If you cannot restructure your app, consider using a Launchpad/Start Menu approach. You create the main entry point with a single view that shows a nice menu of apps available to your users. Each menu item is basically a link to a starting URL for a corresponding module (entry point). When a user clicks on it, this module loads and takes over the entire screen. I would also add an icon to each module to go back to the launchpad.

This way users can bookmark a launchpad, or they can bookmark any module directly.

Note that in this approach URL history would work as expected, i.e. if a user goes Launchpad -> A1 -> A2 -> Launchpad -> B1, etc., a user can hit the back button and the browser will go back one step.

Alternatively, each module can open in a new browser tab. Maybe you can give users an option to choose same tab or new tab somewhere in preferences.

Note that all users of smartphones and tablets are familiar with Launchpad/Start Menu approach, which is also used in Mac OS and, soon, Windows 8. An additional benefit is that each module/app has more screen space to work with.