> Am I trying to provide flexibility that no one is asking for? In my opinion, this is providing flexibility that is not necessary and is not a net positive change to the API. I'm not convinced that it's the right thing to do. However if you were to provide that flexibility, I would agree that get/createHM() is probably a better way to go about it than setHM(). But I think that introducing volatility to the HandlerManager exposes a flaw in the relationship between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan <[email protected]> wrote: > This conversation keeps getting complicated by discussions of policy. I'm > just trying to make it possible for widgets we haven't thought of yet to > define policies of their own. > E.g., to temporarily switch between modes that change the set of events they > source, copying some handlers or not if that's appropriate (perhaps in mode > B I simply am not a source of the events that would happen in mode A. > Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to try > out a singleton HM (I wouldn't, but why should I stop you from trying it > out). > I think JohnL has hit the sweet spot with: > /** > * Called by default implementation of {...@link #getHM} > * to lazily instantiate the HM for this widget. > */ > protected HM createHM(); > /** > * All access to the widget's HM must be made through this method. > * It is an error to cache the object returned. The default implementation > * returns the result of {...@link #createHM} the first time it is called. > */ > protected HM getHM(); > If I override getHM(), I have the option to call the normal createHM() to > get whatever HM the widget normally uses. Or not. If I override createHM() I > can provide a custom implementation, or wrap the normal one, without having > to re-implement the lazy instantiation mechanism. > Am I trying to provide flexibility that no one is asking for? > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
