I realize this is a bit of an old thread; however, I ran across a use
case where I would like to be able to modify HandlerManager. In our
application we would like to be able to "stop" an event from being
fired further.
One example, we have three event handlers that can be added A, B, C
(validation, required check, and save rpc). We add the handlers to a
button in that order when needed (sub class determine which handlers
to add). We want to be able to specify in A or B handler that the
event should stop propagating to other handlers.
We tried a couple of different things (including starting to add our
own event handling logic) and we settled on two changes to GWT
itself. We added a method to GWTEvent:
- public void stop(); /* record that the event should not be passed
to more handlers */
- public void isStopped(); /* is the event stopped for further
processing */
- public void unStop(); /* reset the stop flag to be false - did in
case event is reused */
In our event handlers we can now call event.stop() to stop further
propagation.
In HandlerManager.HandlerRegister we modified
private <H extends EventHandler> void fireEvent(GwtEvent<H> event,
boolean isReverseOrder) {
Type<H> type = event.getAssociatedType();
int count = getHandlerCount(type);
if (isReverseOrder) {
for (int i = count - 1; i >= 0; i--) {
H handler = this.<H> getHandler(type, i);
event.dispatch(handler);
if(event.isStopped()) { // CUSTOM: event stop processing
event.unStop(); // did this in case events are reused
break;
}
}
} else {
for (int i = 0; i < count; i++) {
H handler = this.<H> getHandler(type, i);
event.dispatch(handler);
if(event.isStopped()) { // CUSTOM: event stop processing
event.unStop(); // did this in case events are reused
break;
}
}
}
}
Just thought I would send a quick note in case future changes are
being considered for HandlerManager (realizing 2.0 time frame is
probably off the table).
Chris....
On Aug 7, 12:11 pm, Joel Webber <[email protected]> wrote:
> All,
> There has been a fair amount of discussion about the 1.6 HandlerManager and
> related code, along with a few issues submitted (primarily by Ed), and I'm
> starting this thread to try and reach some kind of consensus on what, if
> anything, needs to be changed about it. Please note that we need to find the
> simplest things we can do to enable everyone's use cases, without creating a
> new event system from whole cloth, or adding a lot of complexity to simple
> use cases. Please help me to reach convergence so that we can get this taken
> care of reasonably soon.
>
> The following are the three issues I'm aware of. I'll work backwards, from
> simplest to most complex.
>
> 1. Switching the 'source' of an event object, primarily for composite
> events.
> We actually did consider this in the original design. This is the normal
> pattern for re-firing an event from a composite (the composite has a field
> called 'button' that represents a wrapped widget):
>
> HandlerRegistration addClickHandler(ClickHandler h) {
> return button.addClickHandler(new ClickHandler() {
> public void onClick(ClickEvent event) {
> fireEvent(event);
> }
> });
> }
>
> This does require the instantiation of an extra inner class, but the design
> allows the HandlerManager to re-use event objects, even when they're fired
> through multiple layers of widgets and composites.
>
> 2. Making the source of a HandlerManager generic (issue 3636).
> Mark Renouf's comment in this issue was spot on: Doing so would break the
> delegation described above. I don't see any way around this. Please let me
> know if I've missed something (but please no proposals that would involve
> redesigning the whole event system).
>
> 3. Adding an "interceptor" to the HandlerManager (issue 3628).
> I'll be honest. I've spent all morning trying to figure out what's being
> requested here, and I just don't quite get it. I'm sure there's a real
> problem being described here, but I think I need a very concrete use-case
> that can't be easily implemented the way things are to fully understand it.
>
> Thanks for your help,
> joel.
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
