On Tue, Feb 9, 2010 at 9:09 AM, <[email protected]> wrote: > Warning: better arguments against setHandlerManager below: > > My concern is that it is too easy to add handlers to a Widget and then > set a new HandlerManager, expecting the old handlers to be transferred > to the new HandlerManager. What would be the correct thing to do here? > We can't transfer handlers because the HandlerRegistrations are linked > to the old HandlerManager. >
Why would I expect that? I'd use such a call expecting it to allow me to swap different sets of handlers around, e.g. a widget that has two very different modes (edit v. nav). > > Also, we've been trying to move to a model where we add Event Handlers > in a widget's constructor instead of overriding onBrowserEvent(). Those > handlers will be lost when we switch to a new HandlerManager, unless we > unregister the old ones and register new ones. That complicates the > widget creation process. > I hope you mean add event handling capabilities at constructor time, not actual handler instances. If you mean the latter, that's a dreadful idea. I still don't buy this argument. If I swap it out, I can swap it in. > If we require that the user specify the one and only HandlerManager when > the first handler is added, then we avoid these problems. I really think this is over protective, and the kind of thing that makes our widgets too hard to customize. > > > > http://gwt-code-reviews.appspot.com/138801 > -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
