I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget.
We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca [email protected] On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken <[email protected]>wrote: > > > 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 > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
