On Sun, Sep 12, 2010 at 4:26 PM, Jarrod Carlson
<[email protected]> wrote:
> 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

but if they are always there, it seems to me like the most convenient
thing to do is never un-register.  The browser will clean up for you
when you navigate away from the page.  If always on means always on,
why ever unregister?


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

I agree with you but for different scenarios.  Keeping track of
multiple handler registrations is annoying, but it's trivial to write
a pool, we do

public final class HandlerRegistrationPool implements HandlerRegistration {
  private final HashSet<HandlerRegistration> registrations = new
HashSet<HandlerRegistration>();
...

which just contains some registrations, removeHandler() calls
removeHandler() on all the registrations it contains.  We use it
internally from the implementation of custom widgets.

All this to say it's trivial to implement but I still wish for GWT to codify it.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to