NoSQL Scalability
Written by: Eugene Ciurana
Featured Refcardz: Top Refcardz:
  1. PHP
  2. Ruby
  3. Caucho Resin
  4. WebMatrix
  5. UML
  1. HTML5
  2. jQuery Selectors
  3. Git
  4. Ajax
  5. CSS Part 1

Link Details

Link 563657 thumbnail
User 258218 avatar

By HamletDRC
via tv.jetbrains.net
Published: Feb 25 2011 / 12:03

This screencast explains why MVC applications benefit from an event bus, and it demonstrates how to create, wire, and respond to events in Google Web Toolkit (GWT). Not bad for just six and a half minutes.
  • 24
  • 0
  • 8069
  • 220

Comments

Add your comment
User 447031 avatar

iirekm replied ago:

2 votes Vote down Vote up Reply

I had a chance to use such event buses in one project and I have to say that I'm dissatisfied. This event bus you've shown is just an example of Observer pattern, the difference is that 'fireXXXEvent', 'addXXXListener' was moved to an object called 'SimpleEventBus'. Unfortunately it has problems:

1) By moving all event listeners to one object (event bus), you have to remember to call 'removeXXXListener' every time a GUI control is removed from the screen, otherwise you may get memory leaks, as objects on the screen appear and disappear if you have complex GUI (ie where GWT is best). This is not a problem for 'enterprise' buses (eg ESB), where modules don't appear that often, but may be a problem for such 'small' buses.
With 'normal' observer pattern each object has its own list of listeners, and in most cases can rely on garbage collector to deallocate memory for you.

2) Observer pattern is self-documenting: when a class has 'addClickListener' and 'addValueChangeListener' it's clear, that it sends 'click' and 'value change' events. This isn't that clear with event bus (unless you explicitly state in Javadocs what events can be thrown).

3) While the design you've shown is quite pretty (because it's just a variation of Observer pattern), the market-leading event bus designs for GWT (eg mvp4g, and others) are just terrible.

User 872029 avatar

hamletatcanoo replied ago:

1 votes Vote down Vote up Reply

These are good points. My thoughts...
1) You *do* need to remove listeners with an event bus or you may get memory leaks. True and good criticism.
2) What I like about Event Buses is that you don't need to re implement a Subject/Observer into every one of your MVC groups. I think if you tried to create an abstraction over many observers then you'd probably end up with something like an event bus. In my experience, the benefits of event buses outweigh the costs.
3) I have only used the GWT Event Bus, and the team I was on was really happy with it. We had a very complex GUI with lots of animations and "when this happens then this other thing occurs" style effects, and we were really happy with the results of using the GWT event bus. I see that GWT MVP is getting popular but I haven't had the chance to try it.

Thanks for the feedback, these are interesting points.

User 447031 avatar

iirekm replied ago:

1 votes Vote down Vote up Reply

[you don't need to re implement a Subject/Observer into every one of your MVC groups]

Yes, the way people typically do listeners in Java is ugly (you have to implement 'listeners' field and add/remove/fire methods). You can do instead:

- add extends EventBase (or something like that); it contains addListener/removeListener/fireEvent methods, but you can't tell what events are raised by just reading method names (addXXXXListener, addYYYYListener has become addListener)

- do something C#-like: event MyEventType eventName. For example in Scala I could do this as: val eventName = new EventListeners[MyEventType], in Java it would be more writing, but is still better than the addXXXXListener/removeXXXXListener/fireXXXXEvent, which was just "inherited" from the agy JavaBeans specification


[I have only used the GWT Event Bus, and the team I was on was really happy with it]
You were lucky you weren't using mvp4g: annotations, kinda reflection (xxxx -> onXxxx), event propagation rules, modules - it makes a real monster from code. :-)

User 872029 avatar

hamletatcanoo replied ago:

0 votes Vote down Vote up Reply

I understand extending EventBase, but it is a suboptimal solution for me because it requires implementation inheritance. I think the Griffon Event System is very good, and I am making a screencast about it today or tomorrow. (yea it's an event system screen cast round up). With Griffon the event keys are just Strings and event handlers are named closures on a controller. It is very slick, as Griffon handles registry and unregistry for you.

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.