Your point being that I could just implement a custom handler manager that can do any of these things, and so should keep Widgets that much simpler, yes? I don't have a good answer to that.
On Thu, Feb 11, 2010 at 10:54 AM, Isaac Truett <[email protected]> wrote: > I don't get why it would be necessary. What would you be able to do by > putting an HM "on ice" that you can't do with the existing API? Why > complicate things? Where's the use case that requires this new API? > > Is this just a philosophical argument over narrowly defined, tightly > controlled APIs vs. more abundant, unrestricted APIs? > > > > > On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan <[email protected]> wrote: > > I don't get that. If I (widget) have nothing to say to you for a while > (am > > not going to be generating the kinds of events that you are registered > for), > > why do you care if my mechanism for achieving that involves putting my > usual > > HM on ice? So long as I don't cause an error if you de-register in the > > meantime, what's the problem? > > > > On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett <[email protected]> > wrote: > >> > >> > 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 > > > > > > > > -- > > I wish this were a Wave > > > > -- > > http://groups.google.com/group/Google-Web-Toolkit-Contributors > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
