-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
>

Reply via email to