AW: JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization

Robert Zenz robert.zenz at
Fri May 29 07:20:47 UTC 2015

Okay, I think I slowly start to see how this will be working. But the logic
within the Behaviors won't go away or be moved, am I seeing this correct?

Maybe I should start with the viewpoint from which I'm looking at it.
The Behaviors contain logic at the moment, various functions that are used
by the skin or the behavior itself (for example the selectNextTab() function
in the TabPaneBehavior). What I'm arguing for is having the possibility to
override such functions at one central point, currently these functions are
called from multiple locations, the skin and the behavior itself. So if I want
to change that function, I can extend the behavior and override the function.

Will such a thing be possible with the new InputMaps, or will I have to rewire
all mappings that use a function in the behavior? What about "hard coded" calls
to functions in the behavior?

Von: Jonathan Giles [mailto:jonathan.giles at] 
Gesendet: Dienstag, 19. Mai 2015 10:50
An: Robert Zenz; openjfx-dev at
Betreff: Re: JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization

It's late and I'm writing this on my phone, but briefly, I think you've missed
the 'project two' section: input maps are how behaviors are now specified,
as a collection of inputs that map to some event handling code.

All skins do in this environment is install a series of these mappings into
the control input map. These are all accessible as public API.

The big thing you miss out on is actually having access to the code within
these event handlers (wish are all gathered in the behavior class). But you can
always replace an input mapping with new code.

I can clarify more tomorrow if things are unclear or if you have any further

-- Jonathan
Sent from a touch device. Please excuse my brevity.

More information about the openjfx-dev mailing list