JavaFX Composer Overview

With the release of JavaFX Composer (the JavaFX GUI builder for NetBeans) I decided to go through a general overview of the tool. With the overview it will answer some key questions which include identifying any missing areas not covered by the tool, point out any of the tool's strengths, point out any of the tool's weaknesses, and look at the major differences between Masisse (the Swing GUI builder for NetBeans) and JavaFX Composer.



Key Questions

Before the release of JavaFX Composer there were some key questions compiled about the tool that needed answers. These questions are:

• Can data binding be done visually?
• Does JavaFX Composer handle creating/editing animations visually?
• Are GUI changes reflected in real time as they occur?
• Is the .fxc file format also used in the JavaFX Authoring tool (for exchanging view data)?
• Can custom JavaFX controls be added to the palette via drag 'n' drop or through a wizard?
• Does JavaFX Composer support visual binding of data to/from a DB?
• What differences are there between JavaFX Composer and the JavaFX Authoring tool?
• What are “states” in JavaFX Composer?
• What advantages will JavaFX Composer have over Matisse?
• What is the relationship between JavaFX Composer and JavaFX Designer?

Differences With JavaFX Composer Compared To Matisse

• Separates the view from the controller and model
• Supports a number of data sources for data binding beyond just DB and general objects
• Supports the ability to do animation visually
• Does not support doing dynamic layout visually
• All generated code is clean and easy to understand
• Handles layout for multiple screen sizes
• Supports the idea of “states” with GUI design for GUI navigation
• Can toggle the display of one or more groups (categories) of properties
• Uses a separate XML type file for storing the GUI design data (not the view)
• Does not allow JavaFX classes, JavaFX controls (custom ones), and JavaFX classes that extend CustomNode to be added to the palette

Advantages

• Can do animations visually for any JavaFX control
• Uses “state” based design
• Generates clean code that is easy to understand and can be customised
• Template system greatly simplifies building forms by having all options in one place and templates can be easily customised after they are created

What To Improve

• Need additional extensibility for JavaFX Composer with the ability to add new JavaFX controls, custom nodes and classes to the palette window
• Have a standard system for developing custom templates that can be added to the palette window
• All public properties for controls and JavaFX classes should be exposed in the properties window
• Real time display of controls that have continuous animations which are started immediately
• Provide official documentation for JavaFX Composer that covers all built in features
• Provide writing capability to all data sources that are supported by JavaFX Composer
• Use the fx source files (which contain the view) instead of the fxc files if two way editing is supported (use a single file instead of two)

Conclusion

Currently the biggest issue with JavaFX Composer is the fact that extensibility is too limited. For example a custom JavaFX control is created and a JavaFX developer wishes to use it with the tool for building a JavaFX application, by adding it to the palette window. Data binding in general is restricted to reading for some data sources (JDBC, File System, File, HTTP). With the next release of the tool one would expect that there will be the ability to write to all data sources.

Templates are a great productivity booster in JavaFX Composer since all options for creating and customising them is under one place. This is unlike wizards where one has to rerun the wizard if anything has to be changed, and not all options are covered by the wizard itself. Also each template produces code that can be easily customised when needed.

At the moment there is an awkward situation where if one edits an fxc file the corresponding fx file is not updated. Also this occurs (in the opposite direction) if one edits the fx file instead. With an fxc file it is more difficult to edit and harder to read compared to an fx file. Why have two different file types present for a JavaFX application's view? It is highly recommended that the fx file is solely used if two way editing is supported in a future release.