An use case is to be able to log all the events that happen in XWiki. It would be stupid to not be able to log an event because there's another event listener that cancels the event before.
On Wed, Oct 17, 2018 at 3:21 PM Marius Dumitru Florea < mariusdumitru.flo...@xwiki.com> wrote: > -0. I would be OK to stop the event propagation if the list of event > listeners were *ordered* but AFAIK there's no order between event > listeners ATM. It should always be possible to catch an event, even if that > event is going to be canceled by some other listener: > > * either by registering an event listener with higher priority than the > one canceling the event > * or by not stopping the event propagation and letting each listener > decide what to do based on the canceled state of the event > > For instance, DOM events have this > https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-capture > > If the capturing EventListener >> <https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener> >> wishes to prevent further processing of the event from occurring it may >> call the stopProgagation method of the Event >> <https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event> >> interface. This will prevent further dispatch of the event, although >> additional EventListeners >> <https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener> >> registered at the same hierarchy level will still receive the event. >> > > So you can always catch the DOM event by registering the event listener on > the element that triggers the event (rather than on one of its parents). > > Thanks, > Marius > > > On Tue, Oct 16, 2018 at 7:07 PM Simon Urli <simon.u...@xwiki.com> wrote: > >> Hi everyone, >> >> the current behaviour of the ObservationManager is to always triggers >> the listeners if it matches the events. >> Now regarding the CancelableEvents, the match is only done on the type >> of the event and some given filter rules, but never with its cancel >> status: if an event is cancelled, the matching listeners are always >> triggered. >> >> I propose to change that behaviour, to trigger listeners only if the >> CancelableEvents are not canceled: basically, a cancelled event wouldn't >> match any listener. >> >> My primary reason for wanting that change is that the current behaviour >> led to a bad UX: if an event triggers multiple questions, no matter if >> one is cancelled, all questions will be asked to the user. >> >> Do you know if the current behaviour is required at some places? >> Else do you agree on changing it? >> >> Simon >> -- >> Simon Urli >> Software Engineer at XWiki SAS >> simon.u...@xwiki.com >> More about us at http://www.xwiki.com >> >