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