Make development of fxml-based applications easier particularly for beginners

[Hallvard Trætteberg]

Hi,

I have taught JavaFX and FXML in an introductory course on object-oriented programming for several years, and now we also use it in a follow-up course.
We use FXML from the start (before they learn much about inheritance) and there are two things that make development more difficult/cumbersome than necessary:
- the need for making a dedicated Application subclass even if it just loads a specific FXML file and the rest is handled by the controller
- the lack of understandable error reporting (exception messages in stack traces) when something goes wrong either during load or in the initialize method

The first issue is annoying when students are working on small assignments or trying out small examples, since there must exist a separate java file with only boilerplate code. To handle this I created my own FxmlApplication class that I provided in a jar and made an Eclipse plugin with a new launch type so they could right-click on any fxml file and choose Run As > FXML application. However, this plugin stopped working when JavaFX was modularized.

The second issue isn't as easy to handle, but it could also be handled by a special Application subclass that catches (relevant) exceptions during fxml loading and tries to make sense of the exception and provide meaningful error output.

In addition to these problems there are minor issues, among others that students expect the top pane to have keyboard focus.

My suggestion is to enhance JavaFX with a (new) FxmlApplication class that extends Application and provides the following logic:
- a start method that looks for an application argument that can be interpreted as a reference to an fxml file (URL or resource)
- if no fxml file reference is provided it defaults to the name of the application class (in case FxmlApplication is itself subclassed) with .fxml appended
- if the fxml file cannot be accessed, an understandable error message is given (rather than e.g. saying location is null in a stack trace)
- the fxml file is loaded, and if the result is not a Scene, it is wrapped in one before being given to the Stage
- the loading is wrapped in expection handling code that tries to provide understandable error messages for typical cases (e.g. misspelled element or attribute name), rather than just ending up with a stack trace that is difficult to make sense of

With such a standard Application class, it shouldn't be difficult to make IDEs support running fxml files directly as explained above.

What do you think and how should I proceed?

Regards,

Hallvard
---
Hallvard Trætteberg (hal at idi.ntnu.no)

Associate Professor, ISSE group, Dept. of Computer Science at the 

Norwegian University of Science and Technology