I don't know if it will help any, but we had issues with the eventbus firing immediately synchronously (not good if the event for a widget fires before said widget finishes attaching and hooking up to receive events!). We ended up creating a deferred eventbus. Seems like you should be able to extend it and get what you want. We create our eventbus as "new DeferredEventBus(new SimpleEventBus())".

import com.google.gwt.core.client.Scheduler;
import com.google.web.bindery.event.shared.Event;
import com.google.web.bindery.event.shared.Event.Type;
import com.google.web.bindery.event.shared.EventBus;
import com.google.web.bindery.event.shared.HandlerRegistration;

public class DeferredEventBus extends EventBus {
    private final EventBus wrapped;

    public DeferredEventBus(EventBus wrappedBus) {
        this.wrapped = wrappedBus;
      }
   
    @Override
    public <H> HandlerRegistration addHandler(Type<H> type, H handler) {
        return wrapped.addHandler(type, handler);
    }

    @Override
    public <H> HandlerRegistration addHandlerToSource(Type<H> type, Object source, H handler) {
        return wrapped.addHandlerToSource(type, source, handler);
    }

    @Override
    public void fireEvent(Event<?> event) {
        Scheduler.get().scheduleDeferred(() ->wrapped.fireEvent(event));
    }

    @Override
    public void fireEventFromSource(Event<?> event, Object source) {
        Scheduler.get().scheduleDeferred(() ->wrapped.fireEventFromSource(event, source));
    }
}



On 10/26/2016 12:51 PM, vitrums wrote:
[ Original post on StackOverflow http://stackoverflow.com/questions/40130383/howto-use-gwt-evenbus-to-schedule-openevent-closeevent-sequence ]

Say we have few handlers for both events. The goal is to make sure, that all OpenEvent handlersfinish before any of CloseEvent handlers start their job. The old EventBus had a reverse order flag, which sometimes helped greatly in these particular cases. I.e. a handler, responsible for launching some process which leads to CloseEvent being fired (i.e. event emitter), usually registers itself to a bus first.

Now, due to a synchronous nature of _javascript_ each handler of OpenEvent ends his job before the next handler starts. In my app the first OpenHandler added to a bus is a CloseEvent emitter. Therefore I get an undesirable sequence of calls: 1st handler of OpenEvent -> all CloseEvent handlers -> the rest of OpenEvent handlers.

My question is: what's the best practice to establish the desirable behavior? So far as a workaround I use Scheduler.scheduleDeferred(Scheduler.ScheduledCommand cmd) to enqueueEventBus.fireEventFromSource(Event event, Object source) of CloseEvent call to the next browser's event loop tick.

p.s. My current thoughts are as follows. I don't want to rely of Timer or Scheduler (though it might be the only option, which I'm not sure about). Also I have no interest in introducing any flag variables, responsible for tracking which event occurred first. Instead, if one looks closer into theSimpleEventBus code, there's a firingDepth counter variable, which only works to delayaddHandler(...) and removeHandler(...) calls. It would be great, if same logic could be applied to order call sequences of handlers for different events.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to