Public Behavior API proposal
Andy Goryachev
andy.goryachev at oracle.com
Mon Nov 20 20:16:49 UTC 2023
Dear colleagues:
I wanted to gauge your opinion on a slightly different approach that addresses both John’s stateless behaviors use case as well as make it unnecessary to change existing event handling APIs but still enforce the right order of event handler execution.
Let’s call it a Split Input Map (more details later).
Control gets an InputMap property which stores the user event handlers and the user key bindings.
Skin has a SkinInputMap, a similar construct, which stores the event handlers and the key bindings registered by the behavior. The SkinInputMap comes in two flavors: one for the stateless behavior use case, and one for stateful behavior use case. In either case the skin input map is set via Skin.setSkinInputMap() (a placeholder name, can be changed).
The difference between the two is the signature of the “function” mapped to a FunctionTag: the stateless requires Consumer<C extends Control>, and a stateful accepts a simple Runnable.
Furthermore, the event handling priority can be encapsulated within the input maps. For example, any event handler registered via either InputMap or SkinInputMap is guaranteed to be called according to its priority. For example, we could have five levels (listed in the order of precedence):
USER_HIGH
SKIN_HIGH
USER_MID
SKIN_LOW
USER_LOW
Basically, event handlers added to the control’s InputMap can have { USER_HIGH, USER_MID, USER_LOW } priority, and those added to SkinInputMap can have { SKIN_HIGH, SKIN_LOW }. This makes it unnecessary to change the existing event handling APIs but solves the issue with undetermined order of event handlers execution that we currently have in Controls.
Comment:
SkinInputMap is basically an equivalent of BehaviorContext in John’s proposal, and priority levels are unambiguous extension of Michael’s EventHandlerPriority.
What do you think?
-andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231120/21d9ee1b/attachment.htm>
More information about the openjfx-dev
mailing list