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.