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 <vitr...@gmail.com> 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 google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > 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 google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
