If you need to swap out two different complex event handling modes of
a widget (where say, a half dozen different events are being
monitored), I think it is too complex to remove all the old handlers
and add new ones every time, I also think overriding onBrowserEvent is
kind of tedious and limited, since every time you need to change the
set being nullified or altered, you need to edit the method.
Consider a paint program with a paint widget, where, depending on
which tool is selected (clone, crop, airbrush, etc) a different set of
event handlers will be active. On some, you may care about drag, or
keyboard, or mouse wheel, or others, you don't.
You could of course write an object that absorbs all the events and
re-routes/broadcasts them as needed, but then all you've done is
simply re-invent HandlerManager and called it 'EventRouter' or some
subject.
Ray * Ray = Ray ^2
:)
On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett <itru...@gmail.com> wrote:
> 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
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
