Note that there are some explanatory texts on larger screens.

plurals
  1. POEvents are causing a chain reaction
    text
    copied!<p>I'm using an Eclipse RCP based framework that suffers from an inefficient event model. Specifically, events emitted by controls often 'cascade'. For example, a control will emit a <code>COLOR_CHANGED</code> event causing the parent composite to propagate the event to sibling controls, which in turn, decide to emit their own <code>COLOR_CHANGED</code> events (in response to the original event), leading to a chain reaction of sorts. I've profiled the app raising over 100,000 events to render a simple form. Frankly, I don't understand how it's not overflowing the stack.</p> <p>So, I'm looking for a technique or design pattern that prevents or reduces this kind of cascade behaviour. I've had a few ideas but this can't be a new problem; there's got to be a 'best practice' out there already for event-oriented design.</p> <p>My ideas:</p> <ul> <li>Events operate like a stack-trace, so new events are chained to their cause. This enables listeners to ignore events that originated from themselves. However, this greatly complicates my event model (and it would be tedious to wrap standard SWT events). Not to mention there are valid use-cases where you might actually want this behaviour.</li> <li>A central 'event pump' is used to raise events. If an event has the same source and payload as a previously raised event within the last <em>n</em> milliseconds, it is discarded. This would hopefully have a doping effect and prevent the events from cascading. Obviously, I can't control how SWT/RCP events are raised but these aren't my main concern.</li> <li>Events should be typed. This seems like a step backwards but I think finer grained events would help performance. For example, <code>ValidationFailedEvent</code> rather than generic <code>Event</code> that everybody handles (and then has to interrogate it's state to determine the event type).</li> </ul> <p>Thanks for taking the time to read about my problem. All advice/suggestions welcome.</p> <p><strong>EDIT</strong>: Thanks to pablosaraiva, I read about <a href="http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern" rel="nofollow">Chain-of-responsibility</a> and now have the following idea:</p> <ul> <li>Events expose an <code>isHandled</code> property which, if set to true, will prevent the event from propagating. This should work when the event's scope is understood but won't help if the event can not be 'handled' by a single control.</li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload