Hi Arthur, I'm not sure what the 'best practice' is, but using our 'gwt- presenter' library (http://code.google.com/p/gwt-presenter) I've ended up tying the Presenters together. In some cases you can be more generic (use @Named to specify a particular implementation of a common Presenter subclass), but generally I've found it's not worth the effort - except for testing.
The downside of binding specific Presenter implementations of course is that we're back to more work when testing, because we now have specific implementations being passed into our Presenter constructors, so they have to be mocked somehow also. The next level of workaround for that would be to create an interface for your shared Presenters and bind to that instead, but it's all starting to get a bit silly at that point. I think the ideal would be to have this wiring done via the EventBus, but I'm still working on a good way of doing that... David On Aug 13, 6:09 am, Arthur Kalmenson <[email protected]> wrote: > Hello everyone, > > I wanted to know, what are the best practices for tying together a > relatively complex user interface in the MVP design pattern. Here's > the problem: > > Most applications have a relatively complex object graph where a top > level domain object will contain a number of domain objects, which in > turn contain other domain objects. Lets take Customer for example. A > Customer has an Account object, which itself contains a Bank object > and a Package object. In the MVP world, you have a View and a > Presenter for Package and Bank. You'd also have the same > View/Presenter combination for Account, but if the View for Package > and Bank have to appear in the same interface as Account, how does one > tie them together? > > We had originally done it by tying the Views together, however, we've > got to a point where we have a View but no Presenter to back it. The > solution is to tie the Presenters together, but the question is, do we > really want all these Presenters tightly coupled to each other? One > can argue that the models contain one another, so it would make sense > that the Presenters/Views would contain one another too. However, this > becomes harder to customize with all the coupling. We're also > following Ray's idea of an EventBus, so we were hoping to keep > Presenters from knowing about each other. Is this not feasible within > one object graph? Any ideas would be greatly appreciated. Thank you. > > Best regards, > -- > Arthur Kalmenson --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
