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
-~----------~----~----~----~------~----~------~--~---
