Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal.
I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken <[email protected]>wrote: > The danger is that if you add handlers, and than later in your code > call setHandlerManager with a new HandlerManager. If we dont check for > a prior existing HandlerManager, all old HandlerRegistration's will be > lost. If you dont know what happened, you will search forever why your > old handlers are not working. > > You wont have the problem with a createHandlerManager method. > > > > On 9 Feb., 17:55, Ray Ryan <[email protected]> wrote: > > If you're right that swapping HMs midstream is a bad idea, I think you > need > > a better argument than "it's a bad idea." What's the actual danger? If > I'm > > making my own HM I'm already pretty savvy. Why tie my hands? > > > > But yes, if you win that point, I agree with the change to replace > setHM(HM) > > with HM createHM() > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
