Thinking outload... What about allowing ctors to take a HM. The other ctors use the default implementation. If you dont care for a HM then use the ctors without HM in the parameter list. That way you dont pollute the widget method list with gets/creates and sets which prolly dont make sense once the thing is built.
On Fri, Feb 12, 2010 at 2:22 PM, 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 > -- mP -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
