We would have to change it.

I never use the ActionEvent myself, and for that you would have

setOnAction

. Since

action

is brand new, maybe we could change it - what do you guys think?

It would bring some extra value to the

action

"overload" compared to the

setOnAction

function.

/me has no idea what is

ActionEvent

and why it is needed

You can get the source and target controls for an action, and prevent event bubbling by consuming it etc. Not very applicable to button actions IMO.

@carlw What about you? You have a strong traditional JavaFX background - do you use ActionEvent from buttons? Have you ever had the need for it in a TornadoFX app?

Most people wouldn't even notice the change (it would require a recompile, but we always do anyways), and if it bites somebody, changing to

setOnAction

solves it.

I've passed data around on buttons because the receiver can make a getSource() call and follow that with userData or properties

@carlw Do you think it would be OK to use

setOnAction

for those use cases?

(catching up)

you don't want to force the functions like save() to require an ActionEvent parameter?

@carlw No, that's boiler plate in 99% of the use cases I think. I see many FXML examples doing that but never touching the event.

fxml doesn't require a parameter in the event handlers...ex @FXML public void save() {}

You could even use

setOnAction(person::save)

if

save

took an

ActionEvent

actually.

This change gives us the ability to use both lambdas and function references for both situations (with/without ActionEvent parameter).

I'm going to commit the change so you guys can see if it messes with any of your code, OK? I'm pretty sure it's a sensible thing to do, but I'll revert it anybody sees any major issues with it.

and with action, there is no "it" object that will point to the event?

That's right.

In the off chance that you'll need it, just write

setOnAction

. That's my theory.

It will save a lot of curlies and parenthesis 🙂

action is just your way of supporting method references then

?

With this change, that's my alibi. Before it was mostly vanity.

it's fine with me. i think there's precedent in the -at-FXML i posted earlier to be loose with the method parameters of event handlers

Sweet! But do let me know if you see any issues with it.

I was working on a slide and my eyes started hurting from all those unnecessary characters 😁

the event object is used more in code that's generating UI element on-the-fly. you can get the source and target and figure out what's been activated. it's less relevant with the typesafebuilders where everything is laid out in a val root or init

@carlw Thanks for putting that into words. I had something similar boiling in the back of my head 🙂

I would also like you guys to consider breaking the

hbox

and

vbox

builders - but don't worry - I'm just talking about removing the

children

parameter. It is a bad match for the builders and should never have been put there. We probably did it before we imagined how powerful builders would become. That's just not the way you use builders, so passing in

children

is probably an anti-pattern. Instead I would like to add optional

alignment

and possibly some other more convenient things.

These could be deprecated for now though, no need to break the API - I just realized that, so no need to weigh pros and cons on this one. Low hanging fruit 🙂