1
votes

We've been using the recommended GWT approach of building parts of our application in an MVP manner. The logic we use is based on Google's examples - the Presenter fetches/prepares data and sets it on the View, and the View contains a reference to the Presenter which it calls (e.g. in UiHandlers).

Some parts of the application which we built should be reused in other views. For example - a view which is sometimes the "main view" of a part of the application - can be used inside a pop-up in another part of the application (of course, the views/presenters are initialized differently in this other case, but basically it is the same thing).

What would be the correct approach to do stuff like this? I cannot seem to find a suitable one without resorting to ugly hacky stuff.

For example - if I put the presenter of the reused component inside the main view - it is easy to initialize the reused component, but it is ugly to receive a result back in the main presenter. This can be solved by passing a runnable or creating a custom handler or passing the parent presenter itself to the reused presenter.

All of these approaches don't seem right to me though and seem ugly. Any ideas/experiences?

2
We thought of EventBus but we don't want to create confusion in the project. On an older GWT project we used the event bus for practically everything and it got horrible soon enough :) Dozens of loosely coupled UI parts communicating via hundreds of events. I find the MVP model simpler to use, but obviously you can't do anything nicely with it. Are there any examples which use both events and presenters so i can try to pry out some best practices out of them? - Vladimir Prenner
I think if should try to find a good balance between using a global EventBus and directly calling components/presenters. I don't have really an example at the hand. But as a general guideline I wouldn't use the global EventBus for UI components. I would handle all the events and state changes of the UI component in the View that contains it. The View can callback on the presenters which might do some additonal logic or fire an Event on the global EventBus if another part of the app/presenter has some interest in the state change of the UI component. - Ümit

2 Answers

1
votes

What you're describing is a view being able to be controlled by 2 distinct presenters. Abstracting those presenters behind a common API, in the form of an interface, should be enough.

You can also see it as a composite widget being used within two distinct views. The composite widget would then expose events and a public API that both views could wire to their specific presenters.

0
votes