On 10 Feb., 16:28, Ray Ryan <[email protected]> wrote: > 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.
Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. > > 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. Yes sure, protected. They should not be public. > > 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. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). > > 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
