Breaking Changes
- #149: The
mvvmfx-cdi
module now uses CDI in version 2 and is now independend fromWeld
. This means you can also use other CDI implementations like Apache OpenWebBeans.
However, this also means that you have explicitly add such a CDI implementation to your dependencies. If you like to use Weld like before you have to add the dependency toweld-se-core
.
New Features and Improvements
-
#249: It is now possible to define a custom path to a FXML file for a view and this way override the naming conventions of mvvmFX. For this add the new annotation
@FxmlPath("/path/to/your/fxml")
on
your view class. An example can be seen here -
#518: It is now possible to provide multipe resource-bundles when loading a view via
FluentViewLoader
by invoking theFluentViewLoader#resourceBundle
method multiple times. -
#491: The ModelWrapper now also supports mapping of immutable data classes.
-
#498: If the
fx:controller
attribute in a FXML file points to a ViewModel instead of a View class now an exception with meaningful message is thrown to help finding this misconfiguration. -
#503: All our internal unit-tests are now using JUnit 5. #504 Together with this change we've introduced an equivalent of the old
JfxRunner
that can be used in JUnit 5 tests to run them in a JavaFX environment with a JavaFX platform thread at hand. -
#131: It is now possible to register customer builder-factories. This can make using custom controls easier in some situations.
-
#481: The
CompositeValidator
now provides an unmodifiable observable list of all it's sub-validators. This can be used to calculate a percentage of valid/invalid sub-validators. -
#332: Prerior to this release you had to implement a method
public void initialize()
to make mvvmFX invoke this initializer method after dependency injection is done. This confirms to the JavaFX initialize naming-convention. In addition to this it is now also possible to define any method with any visibility in a ViewModel as an initializer-method by using the new annotation@Initialize
. This makes it also possible to have more than one initializer method in a single ViewModel. Existing code with the old naming-convention approach still works.