17 Oct
2018
17 Oct
'18
2:24 p.m.
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.florea(a)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.urli(a)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.urli(a)xwiki.com
More about us at http://www.xwiki.com