Does anyone object to adding createHandlerManager now, and then adding getHandlerManager if it is needed later?
Thanks, John LaBanca jlaba...@google.com On Thu, Feb 11, 2010 at 4:09 PM, Ray Ryan <rj...@google.com> wrote: > But I could still override createHM to be a wrapper that is backed by two > separate instances, for example. I'm running out of rationalizations for > providing both methods. And if getHM is missed it could be added later. > > 180 degrees, > rjrjr > > On Feb 11, 2010 1:00 PM, "Ray Cromwell" <cromwell...@gmail.com> wrote: > > 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... > > -- > > 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
