I also don't like the EventBus approach. In my opinion, it decouples exactly the wrong things: While it acts like something you can just throw events onto, and you don't have to care who will handle them, in the end you actually do care. So the coupling is invisible, but logically it's still there. Things get really nasty, as soon as event handlers have to be coordinated (meaning they're not 100% independent). The 'fireInReverseOrder' field of the HandlerManager class is symptomatic.
What we've got here is basically a publisher subscriber pattern, which is a great pattern, if and only if the publisher and all subscribers are absolutely independent (like in a message feed). But with GUIs that's very often not the case. So instead of using an EventBus, I'd do the following: Introduce an 'Operation' interface, and inject operations into your presenters. The presenter then binds these operations. So you get decoupling, testability [*], and allows for much better static analysis of your code. In the projects that I've tried both approaches (non-GWT projects), I found the difference is huge, especially when you encounter a bug. Chris [*] Note: Avoids the ServiceLocator pattern, so it doesn't violate the law of demeter http://en.wikipedia.org/wiki/Law_Of_Demeter . The EventBus basically plays the role of a ServiceLocator from the sender's and receiver's point of view. You don't really know what's in there, and you use the EventBus to get the thing that you actually want indirectly. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
