Stable version 1.3.0 released

Today we have released the new version “1.3.0”.

The biggest new feature is support for Validation. Additionally we have improved the handling of ResourceBundles and the ModelWrapper.

Validation

Validation is needed in most non-trivial applications. While there are third-party libraries that support Validation for JavaFX, most of them don’t fit to the MVVM pattern because the definition of validation logic and the definition of how to visualize errors are coupled.

The new mvvmFX validation support separates the validation logic that should be placed in the ViewModel from the visualization that is located in the View.

More informations can be found in the wiki.

ResourceBundles

It is now possible to define a global ResourceBundle that is used for all views in the application. Additionally the user can now define a ResourceBundle for a FXML file that is included via fx:include.

While this “should” work with standard JavaFX (without mvvmFX) too, in practice a bug in the FXMLLoader prevents the usage of include-specific ResourceBundles in many use cases. With mvvmFX this works in every situation.

All resourceBundles (global, per-view and include-specific) are merged before they are injected into the View/ViewModel. This way you can use values from all three bundles.

ModelWrapper now has “dirty” and “different” flags

The ModelWrapper has two new properties that can be handy for some use cases:

The dirtyProperty indicates whether a change was done to at least one of the properties of the ModelWrapper instance. This can be used for example to enable a “save” button only when the user has changed something.

The differentProperty works similar with the exception that it will switch back to false when the change is revoked by the user. It is only true when there is a difference between the wrapped property and the underlaying model object.

So when the user changes the value back to the old one the “save” button would be disabled again when using the “different” flag while it would stay enabled when the “dirty” flag is used.

Bugfixes

When a notification is send from the ViewModel to the View this notification has to be delivered on the UI thread in any case. This wasn’t done correctly in the past.