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
