Well, when I say "always present", I mean _probably_ always present. So in
this case, simply not unregistering _shouldn't_ be an issue. Your use of a
HandlerRegistrationPool is clever... I might try that; thanks.

Either way, my vote stands: +1 for removeHandler methods. I have options,
but if I were king.... ;-)

~jj


On Sun, Sep 12, 2010 at 5:04 PM, Patrick Julien <[email protected]> wrote:

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

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

Reply via email to