Yes, many times its too hard to customize things. Sometimes it make sense to use private or package protected. But i think the HandlerManager gets used so widely that it should be customizable
On 9 Feb., 23:57, Nathan Wells <[email protected]> wrote: > As a developer I absolutely agree with Mr. Ryan here... I hope that > this isn't taken the wrong way, but it's so difficult to customize any > given tool that GWT hands us. The eventual answer always seems to be > "make a custom build" which is extremely hard to sell to anyone other > than a GWT developer. > > For additional related information, see the following issue: > > http://code.google.com/p/google-web-toolkit/issues/detail?id=3628 > > On Feb 9, 10:14 am, Ray Ryan <[email protected]> wrote: > > > 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
