Dear Martin:
I understand John’s point: you want all the user installed filters and handlers
across all levels to be processed before switching to system level processing.
I also understand this prioritization proposal is designed to push our existing
set of system handlers to a separate phase. But is that all we’re talking about
here? I need some clarification.
If I understand this correctly, this proposal advocates making drastic changes
to the event handling mechanism. Not only it introduces the prioritization
scheme (which I support), but it also alters the way events are bubbled up, by
introducing waves/phases. I am afraid I don’t see the use case for doing that.
In my opinion, the prioritization scheme should work on handlers added to the
same EventTarget. There should be no multiple waves - if an event gets
consumed by an event handler, the dispatching should stop (that change I also
support), if not - it bubbles up the hierarchy.
Within a given control the order of event processing gets involved. If a
Control is subclassed the subclass should get first shot at the event. The same
is true for Behaviors and Skins. Beyond that I’m still not clear if the
behavior or skin should get the event first or if the skin should get it via
the behavior or the other way around. In any case, you’ve got the control, the
behavior, the skin, and all of their subclasses trying to sort out the
execution order.
Hmmm. I am not sure I understand exactly what you are saying.
The way I understand this prioritization proposal is that we introduce a
priority associated with the handler (and not the filter). The proposal
specifies 3 priority levels, I think there might be more, or perhaps we even
have an int priority (might be too much freedom, let’s discuss).
Specifically, I think there might be 5 levels, from high to low (the names are
just for the purposes of discussion):
{ AppHigh, SkinHigh, AppMedium, SkinLow, AppLow }
This way there is absolutely no ambiguity in deciding which handler gets
invoked first. I must note that SkinHigh, SkinLow should not be available to
the application code. At the same time, AppHigh,AppMedium,AppLow levels should
not be available to skins/behaviors.
Side question: should filters also have priority?
Based on this discussion (and I might be mistaken on this) it sounds like
you're trying to handle all this using this proposal, namely registering event
handlers with a prioritization scheme.
Wait, I though that’s what you are proposing, based on the doc
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1
Are you proposing something else, or is something missing from the doc?
Wouldn’t it be easier to just grab the event and pass it around using Java
method calls? Perhaps the call is handleEvent(). A control implements
handleEvent() by passing the event off to the behavior’s handleEvent() which
passes it off to the skin’s handleEvent(). The skin sends it up the superclass
chain by calling super.handleEvent(), etc. so on.
Wouldn’t this be a drastic departure from the established event handling
method? Why call an empty method if we are not interested in the event? Or
maybe I misunderstood you here, what are you asking?
To summarize, I think the idea of explicit priority is a good idea as it solves
the current issue or exact ordering of handlers in the event of skin change, to
give one example. I think we might also benefit from a limited set of
priorities (5) that reflect the reality of fx having two sides - the
application side and the “system”, or skin/behavior, side.
Personally, I find some other ideas problematic: I don’t see a good use case
for multiple waves in dispatching, as this represent a major departure from the
current mechanism, unless I am missing something.
I don’t understand the paragraph about subclassing. Perhaps you mean that if
we have a situation where one class extends the other, they should coordinate
the event handling. For example, the base class would declare the handling
method, register it as a listener, for the child class to override and get the
events? Or the base class should not add any handlers, instead leaving it up
to the child class? But that’s implementation detail.
What do you think?
-andy
From: Martin Fox <mar...@martinfox.com>
Date: Tuesday, October 31, 2023 at 10:13
To: Andy Goryachev <andy.goryac...@oracle.com>
Cc: Michael Strauß <michaelstr...@gmail.com>, openjfx-dev
<openjfx-dev@openjdk.org>
Subject: [External] : Re: Prioritized event handlers
I understand John’s point: you want all the user installed filters and handlers
across all levels to be processed before switching to system level processing.
I also understand this prioritization proposal is designed to push our existing
set of system handlers to a separate phase. But is that all we’re talking about
here? I need some clarification.
Within a given control the order of event processing gets involved. If a
Control is subclassed the subclass should get first shot at the event. The same
is true for Behaviors and Skins. Beyond that I’m still not clear if the
behavior or skin should get the event first or if the skin should get it via
the behavior or the other way around. In any case, you’ve got the control, the
behavior, the skin, and all of their subclasses trying to sort out the
execution order.
Based on this discussion (and I might be mistaken on this) it sounds like
you're trying to handle all this using this proposal, namely registering event
handlers with a prioritization scheme. Wouldn’t it be easier to just grab the
event and pass it around using Java method calls? Perhaps the call is
handleEvent(). A control implements handleEvent() by passing the event off to
the behavior’s handleEvent() which passes it off to the skin’s handleEvent().
The skin sends it up the superclass chain by calling super.handleEvent(), etc.
so on.
This would make for an easy sell to outside developers. We can tell them that
if they subclass a Control and implement handleEvent() they will get events
first during the system phase. The same is true if they subclass a behavior or
skin. They don’t need to buy into or even see a complicated event
prioritization scheme to get exactly what they expect, namely first access to
events.
But, again, maybe I’m off base here. Let me know.
Martin
On Oct 30, 2023, at 12:53 PM, Andy Goryachev <andy.goryac...@oracle.com> wrote:
Dear Michael:
Thank you, this is very helpful.
Questions/Comments:
1. Does this proposal changes the way events are dispatched with respect to
priority? In other words, does it first go through the list of all handlers
registred on the leaf Node (high priority first, then lower, then lowest), then
bubble up? Or do they propagate upwards looking for high priority handlers
first, then the process restarts for lower priorities, as I saw in some
previous emails? (I could be mistaken)
2. Do you propose to abort event dispatching immediately after the event is
consumed? This probably should be mentioned earlier in the Motivation (the
problem statement) section.
3. I wonder if three priority levels are sufficient. Let me explain. We have
two possible actors who can register an event listener: the application code
and the FX (or, rather more specifically, the skin and its behavior, whatever
that might be).
Application code might want to add handlers at three possible priorities:
* App handler must always be called before any fx handler
* App hander does not care
* App handler must always be called after any fx handlers
For fx/skin handlers we might have fewer levels:
* Skin handler does not care
* Skin handler must be called after all other skin handlers
This situation maps to 5 priorities and 4 effective levels (or 5).
We should also mention the fact that when any actor adds two or more handlers
for the same event with the same priority, they get invoked in the order added.
Would you agree, or am I missing some critical aspect of the proposed solution?
Thank you
-andy
From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß
<michaelstr...@gmail.com>
Date: Friday, October 27, 2023 at 19:41
To: openjfx-dev <openjfx-dev@openjdk.org>
Subject: Re: Prioritized event handlers
Here is the proposal:
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1<https://urldefense.com/v3/__https:/gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1__;!!ACWV5N9M2RV99hQ!NvO4B-fpHrjczoDGCoctorfNPX48w38MvW-LOf6ElCk0dBqFX_xPlETcr56POnEaBcwENrIOsX4OKDM0OGc07A$>
Comments are welcome.
On Fri, Oct 27, 2023 at 8:21 PM Andy Goryachev
<andy.goryac...@oracle.com> wrote:
>
> Would it be possible to create a proposal in the JEP format outlining the
> proposed public API?
>
>
>
> Thank you
>
> -andy
