tags:

views:

808

answers:

2

My current process for custom widgets is the following:

  1. Create my widget class - extending Composite;
  2. Create a listener interface for this widget;
  3. Create a listener collection interface - private inner class to the widget;
  4. Create add/removeListener methods on the widget;
  5. Inside the widget, fire the events on the listeners.

My listeners fire fine-grained events, such as onEntityDisplayRequested(Entity entity), so I can't use the stock listeners.

While this achieves low coupling for the widget and allows for re-use, it's quite verbose. Is there a better way of handling design of custom widgets?

+2  A: 

You don't need a separate listener interface for every new widget. E.g. ClickListener is used by a variety of different widget classes. Obviously, some custom widgets will require a new listener type, but that shouldn't be automatic.

Matthew Flaschen
Thanks for the answer. I'm using these listeners to fire custom events, e.g. onEntityDisplayRequested(Entity e) , so I can't use the stock listeners.
Robert Munteanu
Best - and only - answer so far. Winner!
Robert Munteanu
+1  A: 

I think Java faced the same issue some time ago, and a solution was to have the PropertyChange events. They come with - the PropertyEvent, that contains the source, the property name and the old+new values - a PropertyChangeListener - a PropertyChangeSupport, to which you can delegate the event firing, as well as the registering and unregistering the listeners.

You loose a bit of specificity (event are matched by their name as a string), but you can still fire fine-grained events and have some external class support.

I have not used this extensively in GWT, so I can't comment on efficiency aspects.

Pascal