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. Thanks, John LaBanca [email protected] On Mon, Aug 10, 2009 at 9:54 AM, Joel Webber <[email protected]> wrote: > I wasn't directly involved in writing these classes, but having each > subclass' getAssociatedType() be final seems a bit overzealous to me. If you > want to subclass it (which doesn't seem unreasonable), it seems like you'd > *need* to override this method. > @Ray, John: Do either of you recognize any obvious utility in making this > method final? If not, I think it should be made non-final across all event > types. > > > On Sat, Aug 8, 2009 at 3:51 PM, jarrod <[email protected]> wrote: > >> >> Why is the getAssociatedType() method on ValueChangeEvent considered >> final? I'd like to be able to extend this event, but I can't extend it >> if I can't override getAssociatedType(). >> >> Let me explain: >> >> I'm writing a module that is designed to be a base for a slew of other >> "expanded" versions of the module, keeping much of the core >> functionality locked up in a core module and expanding as necessary >> through additional modules. >> >> To be specific, this is a video player module, so some core events >> might be PlayEvent or ValueChangeEvent when the currently playing URL >> changes. Those events should always be generated by the core, but add- >> on modules should be able to respond to those events. >> >> In order to prevent the add-on modules and core components from >> needing to know about each other and adding ***Handlers to all the >> various Has***Handlers in the application, I created a central >> Dispatcher that can register and fire any events - a sort of global >> event bus for all events to come in and get dispatched from. >> >> It works well, but because ValueChangeEvent is generic, I can only >> implement HasValueChangeHandlers for one type on my central >> dispatcher. As it turns out, I need at least two types, and Handlers >> are only interested in one or the other. >> >> To register for the right event, I coded this: >> >> private static Map<Integer, Object> TYPES = new HashMap<Integer, >> Object>(); >> >> @SuppressWarnings("unchecked") >> public static <T> Type<ModelHandler<T>> getType(Class<T> clazz) { >> Integer key = clazz.hashCode(); >> if (!ModelChangeEvent.TYPES.containsKey(key)) { >> Type<ModelHandler<T>> type = new >> Type<ModelHandler<T>>(); >> ModelChangeEvent.TYPES.put(key, type); >> } >> return (Type<ModelHandler<T>>) >> ModelChangeEvent.TYPES.get(key); >> } >> >> So you can register for ValueChangeEvents pertaining to a given class >> type. >> >> However, I need to override getAssociatedType() to do the following: >> >> @SuppressWarnings("unchecked") >> @Override >> public Type<ValueChangeHandler<T>> getAssociatedType() { >> // TODO: Add null check >> Integer key = getValue().getClass().hashCode(); >> return (Type<ValueChangeHandler<T>>) >> ModelChangeEvent.TYPES.get >> (key); >> } >> >> >> So this limits my ability to reuse the ValueChangeHandler on a more >> "global" scope without copy/pasting the class... Unless I am just >> completely distorting the point of the new 1.6 event system... >> >> Help? >> >> >> > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
