ControlsFX Actions

[Jonathan Giles]

Hi all,

I'm keen to gauge public opinion on the ControlsFX Actions API. Do you
use it? If so, do you like it? If not, why not? Do you only use it
because we force you to (for example, in Dialogs)? Would you miss it if
it was gone?

Thanks,
-- Jonathan

[Werner Lehmann]

Hi Jonathan,

thanks for asking, glad to oblige ;-)

I am a big fan of the actions concept and have been using something
similar since it was introduced to Delphi maybe 10+ years ago. The
controlsfx implementation though seems to make me choose between
constructing my scene in FXML, and using action factory methods like
ActionUtils.createButton. It is sad but in this scenario I have to go
with FXML.

My wet dream would be the integration of actions into FX:
- each node (or control?) has an action property
- it can be created, wired and shared in FXML

FXML example:

<fx:define>
<Action fx:id="acDelete" text="Delete" onAction="#delete"/>
</fx:define>

<VBox>
<ToolBar>
<Button action="${acDelete}"/>
</ToolBar>
<ListView>
<contextMenu>
<ContextMenu>
<MenuItem action="${acDelete}"/>
</ContextMenu>
</contextMenu>
</ListView>
</VBox>

Also, nodes could provide standard actions like cut/copy/paste on
TextInputControls. The actual set of actions provided would depend on
the particular node. But that is a minor thing compared to the above.

Werner

[Jonathan Giles]

Off the top of my head, two things we could do are:

1) investigate what needs to be done for better fxml support
2) introduce convenience classes, e.g. ActionButton, ActionMenuItem, etc. This would also help for the fxml case.

Thoughts?

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

[Werner Lehmann]

I'd like to discuss options for better FXML support. Without having
actual action properties on the FX controls I can only think of some
kind of enhancement to the FXML format and/or loader. Maybe another XML
namespace... if processing of this can be plugged into the loader.

As to ActionButton, this could go a long way in the right direction. I
have to say though, I am not a fan of subclassing "the world" (aka all
FX controls). This is bound to be incomplete - especially regarding 3rd
party controls. And it does not work with existing subclasses
("ColorfulButton", "EmployeeListview"). Some people might also like
SceneBuilder support but that is not a priority for me right now.

Do you see a chance to have this baked into FX?

Werner

[Jonathan Giles]

First we prove it in controlsfx, then we can consider baking into JavaFX. Subclassing is a good half way step to prove the concept.

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

[Graham Matthews]

My one quibble with the actions approach may be due to my unfamiliarity with the API but ..

I have several Dialogs where I want to have a slight tweak to the OK button (usually to do some check when they click OK -- like whether to replace a file if the dialog is a save file dialog). To achieve this I have to make my own action, add it to the dialogs list of actions, and then check whether the dialog returns my action rather than the OK action.

I have to do this because as I understand it the OK action is a singleton.

What seems more "natural" to me (and yes I hate arguments based on "natural" since "unnatural" is often just a synonym for "unfamiliar", and could well be here!) is to have the checks for "OK" to be based on the class of the action, not whether it's actually equal to the singleton. This allows for tweaking the OK action and having several actions, all of which are "OK" actions.

Hope that makes sense ..
graham

[Tomas Mikula]

Hi Jonathan,

although I only use actions with Dialogs, I like the concept.

What I wouldn't miss though is the @ActionProxy annotation. I think it
could be easily replaced with a builder API (similar to
Dialogs.create()...). Instead of

public class ActionMapDemo extends Application {
public ActionMapDemo() {
ActionMap.register(this);
Action action11 = ActionMap.action("action11");
Button actionButton = ActionUtils.createButton(action11);
}

@ActionProxy(
text="Action 1.1",
graphic="start.png",
accelerator="ctrl+shift+T")
private void action11() {
System.out.println( "Action 1.1 is executed");
}
}

I would rather write something like

public class ActionMapDemo extends Application {
private final Action action11 = Actions.text("Action 1.1")
.graphic(imagePath)
.accelerator("ctrl+shift+T")
.action(this::action11);

public ActionMapDemo() {
Button actionButton = ActionUtils.createButton(action11);
}

private void action11() {
System.out.println( "Action 1.1 is executed");
}
}

They key point here is that lambdas make it easy enough to turn a
method into an Action. You could get rid of annotation processing,
global register of actions and gain more type-safety, since the
builder API can accept any types, not just string constants.

Just my 2 cents.

Tomas

> --
> You received this message because you are subscribed to the Google Groups
> "ControlsFX" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to controlsfx-de...@googlegroups.com.
> To post to this group, send email to control...@googlegroups.com.
> Visit this group at http://groups.google.com/group/controlsfx-dev.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/controlsfx-dev/150afb2d-8b6e-46c3-be93-12eceaf6ed6b%40email.android.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Mark Schmieder]

I know this is an old post, but a I just joined (belatedly) tonight, and as the Action Framework was a lifesaver for me a few years ago (and still is), I wanted to express my appreciation for this feature even though it has some flaws and oversights that I took care of a few years ago and am only now getting around to vetting here for others' benefit.

I personally think the singleton approach makes sense, as controls in JavaFX are part of a scene graph just as are graphical nodes for shapes and the like. As it also helps to enforce uniform LAF of an application and shared grammar for related terms in an app workflow and layout, I think it makes a lot of sense the way it was done.

In my new job, I inherited a 25 year old application that went from FORTRAN to Matlab to C to Java and is mostly in ancient Swing with old Java 1.3 practices. Much to my surprise, it employs an Action Framework. I never knew that was there, even though I had toyed with some of its components at various times. Somehow the big picture had never seem consolidated enough as a component API within the overall Java framework for me to have noticed how it can avoid problematic code duplication and divergence, even though I did experiment with a couple of the main classes involved.

In contrast, the Action Framework in ControlsFX is very cleanly designed and clearly documented along with essential tools in the ActionUtils class. It was incredibly easy to adopt when I refactored my JavaFX conversion of an old Swing app (around 2017) to use it. I think I did that work in late 2018 to 2019, but everything before the pandemic is a blur at this point.