Hello David, Yeah, we're currently tying Presenters together, and since we're always programming to interfaces, it's easy to mock out the Presenter interfaces that get injected. While using interfaces and Google GIN give us leverage to change the specific implementation of a particular Presenter, we can't make wholesale changes without breaking things depending on this interface.
> 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... This is what we've been thinking about too, and are using it for wiring other parts of the application. For example, we're using the gwt-beans-binding library (http://code.google.com/p/gwt-beans-binding/) for our data binding needs. The actual binding is triggered via the Event Bus, but I'm not sure how a similar concept could be applied to the UI layout. -- Arthur Kalmenson On Tue, Aug 18, 2009 at 12:51 AM, David Peterson<[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
