I was actually thinking it would involve overriding onBrowserEvent().
Maybe I need to have another look at how HandlerManager fits into
things. I thought of it more as a dispatcher directing traffic than
the actual source of event firing. But yes, essentially, it looks like
all of the tools are there already to turn off one type of event and
turn on another. The handlers for the "off" event don't fire because
their event simply doesn't happen. Then you don't have to worry about
which HM is active when a handler is added, making sure they get
removed properly, etc. Simpler, as you said.
On Thu, Feb 11, 2010 at 3:30 PM, Ray Ryan <rj...@google.com> wrote:
> 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 <itru...@gmail.com> 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 <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
>
>
>
> --
> I wish this were a Wave
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
