Ray thanks for the information. Sounds like my novel idea :) has been hashed over a few times.
Hopefully for the next version (3?) collectively there will be some work to try and figure out how to open the event handling mechanism a bit to support developer extensions. They idea about subclassing HandlerManager sounds fine, but I don't see how to make it work with existing widgets. Also, the Widget.ensureHandler() is package private, so subclassing specific widgets doesn't help me - even if I could get them to fire the right event. While I don't like modifying GWT proper, I'm not in the mood to manage an event sub system where I am basically delegating from the GWT events to my event handling (even if it is basically copy and paste). I'll keep that idea in the back of my mind in case I have other use cases that require further extension. Besides, I have two other small changes to GWT (modify a constructor access permission on DecoratedPopupPanel and replace the Date_serializer) so what is one more managed change :) Thanks again, Chris.... On Aug 28, 2:16 pm, Ray Cromwell <[email protected]> wrote: > I had a discussion about this and other propagation issues for non-DOM > events a long time ago when the 1.6 event system was being designed. At the > time, I believe the consensus was that propagation for custom events was a > complex subject and should be left for developers to subclass HandlerManager > and GwtEvent. For example, I had a quite complex use case where I was > implementing synthetic widgets drawn on a Canvas and I needed both capture > and bubbling behavior with totally custom events. Thus, I would subclass > GwtEvent as VirtualEvent and add stopPropagation/preventDefault/etc. I would > also subclass HandlerManager so that it would perform the checks you > outlined above, as well as propagating events between sources. > This was on the old incubator, and it looks like in 1.6, some decisions were > made that makes this more difficult now, as HandlerRegistry is a private > class which cannot be overriden (probably for efficiency), thus > HandlerManager is kind of frozen in stone, so you either have to patch it > (it seems too late for this), or just copy it wholesale. There's no real > harm in creating a totally separate HandlerManager implementation, like a > HandlerManagerWithPropagationModel. > > -Ray > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
