Yes I understand that the addHandler methods return a HandlerRegistration. In the application I am working on, there are a few pieces of the UI that are "omni-present", if you will. They are (almost) always there, regardless of application state or the current history token and they do not participate in navigation of the application (example: a global navigation menu). For these components, the forthcoming Activity/View system didn't seem appropriate; my components are better built as Widget subclasses with a delegated controller if necessary. However, these components still need to send and receive messages from the application's event bus.
In these specific components, I have chosen to let the class implement the desired handler interfaces, rather than creating many anonymous inner classes. This way, I can use *this* for the "handler" argument in addHandler. Depending on the class, I may be listening for a number of events. In such case, it would be much more convenient to use a removeHandler method, again passing *this* as the handler. For example, I might register the handler during the Widget's onLoad() method, and unregister the handler in the onUnload() method. The request is merely one of convenience, since passing *this* to the removeHandler method is much simpler than trying to keep track of two, three, five or more HandlerRegistrations. ~jj On Sun, Sep 12, 2010 at 1:18 PM, pjulien <[email protected]> wrote: > You're aware that addHandler* returns a HandlerRegistration object > correct? You can call remove the handler by doing > > HandlerRegistration r = eventBus.addHandler(...); > > r.removeHandler(); > > but most times, you won't need to track HandlerRegistration objects or > call remove handler since an event bus decorator called > ResettableEventBus is usually what is received from activities. > > That being said, I find it useful to have a pool class that is used > from custom widgets where an event bus is not passed in but used > internally. > > To answer your question. HandlerManager is deprecated. > HandlerManager.HandlerRegistry has been renamed SimpleEventBus > > > On Sep 12, 11:54 am, jarrod <[email protected]> wrote: > > Ray, > > > > I read through as much of the review as I could. Forgive me, but it's > > an awful lot of information to wrap my head around, especially without > > some context to consider it in. > > > > If I understood the gist of it correctly, it sounds like the problem > > is overuse of HandlerManager for tasks it was not originally designed > > for. The refactoring goal, then, is separation of concerns; namely > > that HandlerManager should be relegated to support of DOM events in > > Widgets, while EventBus is a new but related class designed to handle > > application-level event notification. > > > > Did I get that right? > > > > Even so, I think it would still be helpful to have a removeHandler > > method on the EventBus for convenience. > > > > On Sep 11, 9:32 pm, Ray Ryan <[email protected]> wrote: > > > > > > > > > Please see the discussion here: > > > > >http://gwt-code-reviews.appspot.com/841804/show > > > > > We much prefer to keep the api minimal. > > > > > On Sat, Sep 11, 2010 at 5:24 PM, jarrod <[email protected]> > wrote: > > > > Is there any reason NOT to add the following method to the EventBus > > > > interface? > > > > > > <H extends EventHandler> void removeHandler(GwtEvent.Type<H> type, H > > > > handler); > > > > > > This would make it much easier to adopt the use of EventBus > throughout > > > > my application instead of referring to the HandlerManager concrete > > > > implementation. > > > > > > Shoot, maybe all of HandlerManager's public methods should be part of > > > > the EventBus interface? > > > > > >http://code.google.com/p/google-web-toolkit/issues/detail?id=5271 > > > > > > -- > > > >http://groups.google.com/group/Google-Web-Toolkit-Contributors > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
