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
