In MVP, should presenters instantiate and control other presenters?

Question

I've implemented an application using MVP with GWT, which is working out very nicely for views that have a single purpose. Now, it has evolved into views that are achieving multiple purposes in a single window. So now I have a view of views with each view having its own presenter. I used this example as my model for building out the application, take a look.

The "view of views" also has its own presenter, which instantiates (or receives) the presenters for each of the other views it needs to fulfill its purpose. I reveal event interfaces through those presenters for the "view of views" presenter to hook into and listen and react to what's going on inside those other presenters & views.

My questions are:

• Am I still following MVP principles or have I violated the separation of concerns somewhere by having presenters create/receive and control other presenters? aka Should I be doing this?

• What are some other design patterns for creating interfaces that are also composed of other complex interfaces?

Update

In response to Robert Harvey's question, there is difficulty with passing objects from a presenter of a view to the presenter of the "view of views" when an event is triggered. For instance, a button will flag a ClickEvent and the handler attached to this will need to pick up the data object related to the ClickEvent through another method revealed by the view's presenter. So this works, but do feel it will cause more problems later on as this kind of object handling grows in complexity.

Answer 1

In order to make it easier for the presenter at the lowest level to interact with the views of other presenters, I just added a method to the interface of the various presenters to return the view they are controlling. This way I can hook my presenter at the lowest level into the events of those views.

If anyone can point out any problems this will cause down the line, I am all ears. Thanks!

Answer 2

Sorry for replying to this so late but someone else may see this....

This is a common issue on Android and the usual solution is to have the views implement interfaces owned by the calling views.

This makes a real mess however, and really makes it hard to know whats going on.

We solved this is issue by using the Observer pattern embodied in a Bus (EventBus) from square.

The presenters registered for events and told their views when necessary because sometimes they also needed to do other things (make network requests, store data in db, etc).