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 <rj...@google.com> 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