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.

JFX Blocks (Core) 0.2 Released

On the 15th of December (NZDT) JFX Blocks (Core) 0.2 was released on Kenai. This release covers the following:

• General utilities
• Application specific utilities and the basic part of the application lifecycle
• Basic IO facilities (reading from an InputStream and writing to an OutputStream)
• Lookups of resources in Storage and in the application's JAR (has a basic lookup system)
• Type converter for handling conversions between reference and primitive types (especially handy when using parts of the Java API that expect and/or return a primitive type)

Do note that this release has not been tested on the mobile side since there is no JavaFX mobile emulator for Linux at the moment. Temporarily provided with the release is a mixin for creating test cases (for Unit Testing) which will be removed with a later release of JFX Blocks (Core). As for samples there is a single one that will be released on Kenai soon. In many ways the JFX Blocks release pushes the boundaries of what JavaFX is capable of, and even exposes some areas that need to be addressed (e.g. the need for a Map data type).

Feel free to provided feedback since this is an experimental release that is exploring how to best provide a library to meet the needs of JavaFX developers. It has only just scratched the surface with meeting some of these needs. In particular the core part of the library is trying to address common functionality that a JavaFX developer needs in a new or existing JavaFX application.