Skip to content

1.7.0

Latest
Compare
Choose a tag to compare
@manuel-mauky manuel-mauky released this 30 Jan 13:23
· 65 commits to stable since this release

Breaking Changes

  • #149: The mvvmfx-cdi module now uses CDI in version 2 and is now independend from Weld. 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 to weld-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 the FluentViewLoader#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.