John, The concern you raise is valid - how should one register sub-classes for the right event, and should sub-class event handlers still be able to handle super-class events?
I did run into this as well, and while I think it is a concern, I was more immediately concerned with the issue at hand (extending ValueChangeEvent). In my application's case, my goal is essentially to have a centralized, singleton instance of a HandlerManager so that events can be distributed at a global level. I'd like to do this so that add-on components can register and listen for events without needing to know about the specific instances of other components that generate the events (think plugins, and no Spring for dependency injection). So far, the way I've handled this is to create a class called Dispatcher that extends HandlerManager and implements EntryPoint. Then, any class that wants to register as a global listener can just use the global HandlerManager instance and the registration method takes the event Type for which you are registering. Observe: public class Dispatcher extends HandlerManager implements EntryPoint, HasHandlers { private static Dispatcher instance; public static Dispatcher get() { return Dispatcher.instance; } private Dispatcher() { super(null); } @Override public void onModuleLoad() { Dispatcher.instance = this; } } There are certainly some shortcomings with this method, so I would welcome suggestions or improvements, but centralized event dispatching is something I'd really like to see as a core function of GWT's event handling system. Thanks! On Aug 10, 10:39 am, John Tamplin <j...@google.com> wrote: > On Mon, Aug 10, 2009 at 10:26 AM, John LaBanca <jlaba...@google.com> wrote: > > I believe the problem is that if you extend ValueChangeEvent and > > ValueChangeHandler, you can then call > > Widget#addHandler(mySubValueChangeHandler, ValueChangeEvent.getType()), > > creating a mismatch because you are associating a SubValueChangeHandler with > > the ValueChangeEvent type. While I don't think this will cause technically > > any problems, it can lead to a little confusion because if you fire a > > SubValueChangeEvent, your handler will not fire. > > > Still, I think we can just javadoc that and take off the final modifier. > > This could be useful in that you could register a change handler that takes > a superclass event, and register it for some number of specific subclasses > that you want to handle. > > Ideally, there would be a way to register a handler for all subclasses as > well, ie: > > addHandler(ValueChangeHandler<FooSuper> handler, FooSuper.getType()); > > and it would get triggered on FooSub1, FooSub2, etc as well. > > -- > John A. Tamplin > Software Engineer (GWT), Google --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---