Re: HowTo use GWT EvenBus to schedule OpenEvent -> CloseEvent sequence
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.
Re: HowTo use GWT EvenBus to schedule OpenEvent -> CloseEvent sequence
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.
Re: HowTo use GWT EvenBus to schedule OpenEvent -> CloseEvent sequence
Given that JS is single threaded using Scheduler.scheduleDeferred is your only option. You could write your own EventBus implementation that might use Scheduler.scheduleDeferred internally so that an event, fired during another event being processed, gets delayed to the next browser event loop. Generally I try to code things independent of ordering assumptions, especially if the EventBus interface your are programming against does not define any ordering rules. Might be better to have a class that knows how many open events to expect and is then responsible to fire close event(s), some sort of an open/close event manager. That way you have your specific requirement explicitly documented in code rather than implicitly covered through some EventBus implementation (that might change). -- J. -- 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.
Re: HowTo use GWT EvenBus to schedule OpenEvent -> CloseEvent sequence
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 HandlerRegistration
addHandler(Type type, H handler) {
return wrapped.addHandler(type, handler);
}
@Override
public HandlerRegistration
addHandlerToSource(Type 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 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 th
HowTo use GWT EvenBus to schedule OpenEvent -> CloseEvent sequence
[ 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.
