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.gi...@oracle.com] Gesendet: Dienstag, 19. Mai 2015 10:50 An: Robert Zenz; openjfx-dev@openjdk.java.net 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 questions. -- Jonathan Sent from a touch device. Please excuse my brevity.
