On Tue, Nov 11, 2008 at 2:30 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
> I'm not sure if the event preview mechanism would completely solve all > the problems, but it appears to offer essentially an "override" > capability to fireEvent. If you recall our earlier discussions, the > use case goes something like this: > > > What I'm not sure of, is if I shoe-horn all this functionality into > the preview mechanism, if it will still play nice with all the > fireDepth/queuing stuff that was recently added. > > Yes, that was the use case that I has in mind, and it plays nicely with the fireDepth/queuing mechanism. The use case in analogous to onAttach and onLoad, in that basically we need to be able to perform setup and teardown actions before/after the user code runs. Originally I had a protected method onBeforeEventFired, but Ray R. pointed out that if we instead delegated to a listener, it would be more flexible then forcing everyone to subclass handler manager while still allowing us to subclass handler manager when required. In your use case, I was actually assuming that your PropagationModel would implement GwtEventPreview directly, and be installed where ever appropriate, thereby avoiding a whole bunch of subclasses of widgets and the handler manager itself. -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
