Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

EventBus role in GWT

Tags:

gwt

event-bus

I read up about this cool event handling in GWT using EventBus and so far I really like it. But I don't really grasp the concept when should I use it. All the time? Can I overuse it? Should I use it for everything event-related? (Like communicating between the view and presenter layer in MVP? Or can I use it with onMouseMove event? How heavyweight is it?)

So in one question: What exactly the role of EventBus in GWT?

like image 285
Croo Avatar asked Nov 30 '11 13:11

Croo


1 Answers

You have probably seen this Google I/O presentation: Google Web Toolkit Architecture: Best Practices For Architecting Your GWT App.

It covers neat techniques to make working with a large GWT projects more managable, like using the Command Pattern for RPC calls, the MVP pattern, Dependency Injection, and decoupling components using the EventBus pattern. Now there are several GWT frameworks that implement these patterns, (gwt-dispatch for Command pattern, gwt-presenter and gwt-platform for MVP, GIN & Guice for DI) but the thing I like about the EventBus concept is that it's part of the core GWT framework (HandlerManager), so I don't have to add extra dependencies to smaller GWT projects.

I think the EventBus concept is related to the Observer design pattern in the sense that you are decoupling the View components responsible for getting user input from the Presenter components that need to be notified about those actions. The point is that your ListBox thingy doesn't have to know about all the components that are interested in its state change, it just fires an event to the EventBus, and the interested components will receive that event and act however they want.

I don't think you always have to do things through the HandlerManager instance though. Suppose you have a custom DateRangePicker widget, that lets users pick custom date ranges. Whenever a date range is picked, the widget can do something like this in its onSomethingChanged() method :

NativeEvent event = Document.get().createChangeEvent();
DomEvent.fireNativeEvent(event, this);

Then the components interested in the date range selection change could just register hander callbacks to the DateRangePicker widget instances.

dateRangePicker.addDomHandler(new ChangeHandler(){
    @Override
    public void onChange(ChangeEvent event) {
        refresh();
    }
}, ChangeEvent.getType());

I think this is a nice loosely coupled design and it doesn't use a HandlerManager instance.

A bad design would be to call all the interested component's refresh() methods in the DateRangePicker's onSomethingChange() method instead of firing an event. (Or even worse: calling all the refresh()-es in, the DateRangePicker object's subcomponent's onSomethingChange() methods.)

like image 121
andras Avatar answered Oct 04 '22 02:10

andras