I agree, you could do it that way. I'm trying to think of a case where it wouldn't be good enough, I guess in theory, you could have a widget that can't be subclassed/overridden where set/get methods could allow you to override or inject HM dependencies, whereas the create technique isn't as DI friendly.
-Ray On Thu, Feb 11, 2010 at 1: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
