Updated the patch to only add a createHandlerManager which gets called by ensureHandlers.
On 12 Feb., 04:22, John LaBanca <[email protected]> wrote: > Alright, lets go with createHandlerManager() for now. Thanks for all the > feedback. > > @sven - > > Would you like to update the patch by reverting the getHandlerManager() > method back to a package protected method? If you don't get to it for a few > days, I'll can do it for you. > > Thanks, > John LaBanca > [email protected] > > On Thu, Feb 11, 2010 at 9:39 PM, Nathan Wells <[email protected]> wrote: > > I'd say that if you wanted to implement a HandlerManager stack, it > > would probably be best to do that internal to the HandlerManager, > > rather than forcing a Widget to know how events are handled. > > > Assuming that is possible given the current Widget implementations > > (others more expert than I would know this, probably), the only API I > > would want is createHandlerManager(). I could then manage how that > > more complex HandlerManager is dealt with. > > > While we're on the subject... if you're providing this factory method, > > I would rather see a well-documented interface to implement rather > > than a semi-documented implementation of which I would probably be > > overriding every method. > > > just my .02 > > > On Feb 11, 11:05 am, 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
