Generating plain Java code without FXML?

[chengenzhao]

Hi:

As discussed on Twitter: https://twitter.com/WhiteWoodCity/status/1480842744889507847

Is it possible for Scene Builder to generate plain Java code without FXML?
A lot of ppl are using JavaFX without FXML so would be nice to have FXML optional?
If so, this tool will be more useful and adopted

Based on our experiences, developers are usually more familiar with Java code rather than XML
Some of them are even hate XML because it is not IDE friendly
Hints and suggestions often collapse when using XML code but works very well for Java code
and some example projects have abandoned XML and using plain Java code to create MVC project
https://github.com/Pi4J/pi4j-template-javafx

So if we could have option to let the Scene Builder generate code with and without FXML
then developers could choose the development way they prefer

Thanks

[Oliver-Loeffler]

Well, I have worked on the code to generate Controller Skeletons (View / Show Sample Controller Skeleton).
Those skeletons can be configured to be created either in Java or Kotlin and to contain comments. There is also an option which is called Full at this moment.

Full means, that all elements declared in the FXML will appear in the controller, regardless if there is an fx:id defined or not.
Here we could introduce another option, which creates a Controller Skeleton which would work without requiring the FXMLLoader.
If we'd go from there, we would have to agree on a strategy, how and where objects are declared. The FXOM already holds the graph as it will be declared in the FXML. From there, constructor calls and calls to methods such as getChildren and add are required.
For instance, all the objects could be created in the constructor. This would be like option Full with a possibly new option such as Create Nodes.

With having the feature placed in the Show Sample Controller Skeleton function, the way how Scene Builder is used won't change. You would be still able to save FXML but also to create code from there.

What do you think?

[chengenzhao]

Very nice step
Thank you very much
Please make it happened

[chengenzhao]

  public BattleFXGLPane(Stage stage, Map<Object, Object> parameters) {
    super(stage, parameters);

    var fxglPane = Game.embeddedLaunch(new Game(parameters));

    Stop[] stops = new Stop[]{new Stop(0, Color.web("3372b5")), new Stop(0.5, Color.web("b3e7fa")), new Stop(0.9, Color.web("a4c9bd"))};
    LinearGradient linearGradient = new LinearGradient(0, 0, 1, 1, true, CycleMethod.NO_CYCLE, stops);
    fxglPane.setRenderFill(linearGradient);

    fxglPane.prefWidthProperty().bind(widthProperty());
    fxglPane.prefHeightProperty().bind(heightProperty());
    fxglPane.renderWidthProperty().bind(widthProperty());
    fxglPane.renderHeightProperty().bind(heightProperty());

    getChildren().add(fxglPane);
  }

We write the code in the way of you suggested
init components in the constructor and use get children add etc.

[Oliver-Loeffler]

That was what I had in mind. Well, possibly starting with the nodes first. Properties and styles though is still something to think about. But this problem can nicely be broken into many little steps.

[julianjupiter]

Perhaps, as additional option for designing UI, we bring back JavaFXScript. It’s declarative and seems to be easier than XML.

[mipastgt]

Instead of inventing a new (or bringing back a dead) language it is probably better to just switch to Kotlin and use a DSL (like in TornadoFX).

[julianjupiter]

Switching to different language is far better solution. My concern is only for UI itself but when it comes to logic I’m ok with Java.

[Oliver-Loeffler]

This approach should work for Kotlin and Java. If done the right way, one could add strategies to serialize the FXOM code using a given DSL such as TornadoFX.

[chengenzhao]

Hmm.... FX Script may be not a good idea
Modern IDE could provide very nice instant help and debug info for Java(and Kotlin maybe)
while it may not provide such nice service for other languages like FX Script
so FX Script probably wont behave better than FXML in this scenario
and Modern compiler like Graal could provide AOT compilation for Java, Kotlin etc.
and at least for now, Graal doesn't provide AOT compilation for Truffle languages
so for this consideration, importing a new or reviving a dead language is not a good idea neither
If we want to import a new language other than Java, I think Kotlin is a better option