Another example from GWTP https://github.com/ArcBees/GWTP/blob/master/gwtp-core/gwtp-mvp-client/src/main/java/com/gwtplatform/mvp/client/proxy/PlaceManagerImpl.java, as Jens said, having a manager controlling the ordering of the events seems a good idea. And PlaceManager control the ordering of various event fired in the eventBus like FireRequestInternalEvent, LockInteractionEvent and NavigationEvent. LockInteractionEvent is a dual event, one for lock start, and the second for the lock ends, which looks similar to your case.
On Thu, Oct 27, 2016 at 2:22 AM vitrums <[email protected]> wrote: > Thank you for quick responses. It seems that we all resorted to Scheduler > and control our custom events by tweaking the intrinsic logic > of browser's event loop. I thought I could completely miss some obvious > solution. > > > On Wednesday, October 26, 2016 at 7:51:19 PM UTC+3, 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 handlers*finish 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 enqueue*EventBus.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 the*SimpleEventBus* code, there's a *firingDepth* counter > variable, which only works to delay*addHandler(...)* 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.
