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.

Breaking Changes

• #454: The validation feature was moved into it's own sub-module. This way it's possible to use the validation classes without importing the whole mvvmFX framework. If you are using the validator you have to add the new dependency to your maven/gradle build script:

<dependency>
        <groupId>de.saxsys</groupId>
        <artifactId>mvvmfx-validation</artifactId>
        <version>1.6.0</version>
</dependency>

The API and packages of the classes haven't changed so everything you have to do to get your build file.

• #308: If using a dependency injection framework you can add @PostConstruct to methods to execute setup code after a class was created and has all dependencies injected. However, if you name this method "initialize" in a ViewModel then this conflicts with the initialization logic of the mvvmFX framework. In this case the method will be invoked 2 times. See the wiki for a detailed explanation. In this situation now an exception is thrown. To fix this you have to rename your @PostConstruct method. This change is potentially a breaking change for some users even though it's unlikely that this combination ever worked properly anyway. Thx to @sideisra for reporting and to @SirWindfield for fixing.

New Features and Improvements

• #381: ViewModels now support a basic lifecycle to react on the event of the view being added to or removed from the Scene. This way you can implement cleanup logic in your ViewModels to prevent possible memory leaks. See the wiki page for more informations.
• #349: Next to the existing CDI and Guice modules for dependency injection there is now a new module for the EasyDI dependency injection library. EasyDI is a small library for small to medium sized projects. While it's not as powerful as CDI or Guice, it has less configuration overhead and can be much faster then the other two in some situations. Thx to @SirWindfield for the implementation.
• #443: It's now possible to add more complex validation rules to the ObservableRuleBasedValidator. Previously it was only possible to add ObservableBoolean rules with a fixed message. Now it's also possible to add an Observable<ValidationMessage>. This way you can define dynamic messages that are used when the validation fails. See the wiki for a short example. Thx to @gtnarg for the idea.
• #423: The ModelWrapper now correctly sets the name attribute of each created JavaFX Property. Thx to @pkantner for the proposal.
• #421: The ModelWrapper now has a method copyValuesTo which takes a model instance as argument and copies all current values of the wrapper into the provided model instance. Thx to @pkantner for the proposal.
• #345: The ListTransformation class has a modelList property which is now renamed to sourceList. The new name better reflects what the class is doing by using "source" and "target" as terms. The old modelList property is still available but is now marked as deprecated and will be removed in a future version. Thx to @tranquility79 for implementation.

Bugfixes

• #442: The DelegateCommand didn't provide access to an exception that was thrown by the executed action when the command was executed in synchronous mode. You can now access such exceptions with DelegateCommand.getException() method. Thx to @AKreisel for reporting and to @tranquility79 for fixing.
• #399: A DelegateCommand wasn't able to be restarted properly. Thx to @tfleis for reporting.
• #441: It was possible to subscribe to a NotificationCenter with null as subscriber. Later, when unsubscribe is invoked this was resulting in a NullPointerException.
• #435: When a resourceBundle is injected with @InjectResourceBundle annotation then an exception should be thrown when no resourceBundle was provided when loading the scene. This wasn't the case anymore due to a regression in the code.
• #426: Injecting a Scope Context with @InjectContext wasn't working when an existing ViewModel instance was used for loading the scene. Thx to @sideisra for reporting.
• #419: The ListTransformation class was using an immutable list internally for the model list in some situations. This was resulting in UnsupportedOperationExcepion when new model elements are added to the model list, which of cause is a reasonable usage. Now a normal observable ArrayList is used.
• #415: With version 1.51. we introduced a regression by changing the implementation hierarchy of the CompositeValidator which breaks custom ValidationMessage implementations. Thx to @gtnarg for reporting.

Documentation and examples

• #447: The Contacts example was using an old version of ControlsFX which isn't supported on newer JDKs like 102 and 112. Thx to @bekwam
• #446: There is a new example app that shows how to implement asynchronous behavior with Java CompletableFuture.

His is a hotfix release. Bugs:

• [#413]: Validation status of CompositeValidator was wrong when multiple child validators had the same validation message.

This is a bugfix release.

ModelWrapper

• #404 A NullPointerException was thrown when useCurrentValuesAsDefault is invoked when no model instance is set in the ModelWrapper
• #402 When a new model was set the default values were overwritten. Thx to @johnp for fixing.
• #393 When the user created a field of Type StringProperty that uses another StringProperty as accessor (instead of simple getter and setter), the default value wasn't applied. Thx to @johnp for fixing.

Validation

• #398 In version 1.5.0 we introduced equals and hashCode methods for ValidationMessage class. This change introduces a problem with the CompositeValidator when multipe validators were producing ValidationMessages with equal message text and severity. Now the CompositeValidator handles such cases correctly. Thx to @tfleis for reporting.

Other

• #310 DelegateCommand wasn't executing callbacks for "succeeded" and "failed" when used in synchronous mode.

This version contains many improvements and small features. Additionally we are releasing a first version of our Scopes feature.

New Features

• After a lot of work durring this release cycle we have introduced a first version of our Scopes feature. A Scope is a data context that can be used by multiple components to share common data without tight coupling between each other. While there are still some open questions and issues with this feature (#383) we have decided to release it so that potential users can try it out and provide feedback. This means the Scopes feature is in BETA state at the moment. See the wiki for more informations on how to use scopes.

Small Features and Improvements

• #384: The executable parameter of DelegateCommand is now of type ObservableValue<Boolean> instead of ObservableBooleanValue. This can simplify the usage in some use cases.
• #286: Introduces WeakNotificationObserver. This can be used as wrapper for the NotificationObserver to prevent memory leaks. This is similar to WeakChangeListener of JavaFX. The usage is described in the wiki.
• #369: The DefaultNotificationCenter is now public and has a public constructor. This can be useful for testing purposes.
• #356: The initialization of an existing ViewModel instance was inconstent between JavaView and FxmlView. When an existing ViewModel instances was passed to the FluentViewLoader when loading a JavaView, the initialize method of the ViewModel instance was invoked by the framework in previous versions. Now this isn't the case anymore. This behaviour is constistent with the existing behaviour of FxmlViews. For users of JavaView this may be a breaking change because existing logic that depend on this behaviour may not work anymore.
• #350: The FluentViewLoader was missing the possibility to provide an existing CodeBehind when loading JavaViews. This is now fixed.

ModelWrapper

• #376: The order in which the ModelWrapper commits and reloads values is now deterministic. In the past the order wasn't specified but now can be assumed to be deterministic. Thanks to @sideisra.
• #372: The ModelWrapper now has an additional constructor taking an ObjectProperty of the wrapped model type. When the value of the property changes the ModelWrapper will reload it's internal values automatically. Thanks to @sideisra.
• #366: The ModelWrapper has now the possibility to update the default values for it's fields. This can be done by calling useCurrentValuesAsDefaults method. Thanks to @sideisra.

Validation

• #364: The ValidationMessage class has now a proper implementation of equals and hashCode methods which makes testing of validation logic easier.
• #359: The ValidationMessage class has now a public constructor to support subclassing.

Bugfixes

• #376 Fixed a potential memory leak in the direct notification mechanism between ViewModel and View due to the fact that the ViewModel instance was used as channel identifier.

This release contains some bugfixes:

• [#335] ViewModels were not injected when Guice AOP interceptors were used. Thx to @archislav for reporting and helping to find the issue.
• [#311] exceptions were silently catched when `DelegateCommand' was used in synchronous mode.
• [#319] the injection behaviour between JavaView and FxmlView was inconsistent when no generic ViewModel type was defined. In case of JavaView now an exception is thrown to match the behaviour of FxmlViews.

This release contains mostly improvements and bugfixes:

Improvements

• [#221] The ModelWrapper now supports mapping for (observable) lists. Thx to @lihop for this contribution.
• [#247] JFX-Testrunner is now integrated in mvvmfx-testing-utils. This util is still in beta state and will be further improved in the future.
• [#275] The CachedViewModelCellFactory now supports customization of the ViewListCells.
• [#287] The implementation of the NotificationCenter can now be replaced with the new Method NotificationCenterFactory.setNotificationCenter(...). This can make testing easier because you can now use a mock notification center.
• [#258] The GCVerifier had a dependency to the assertJ library. This dependency was removed.
• [#293] The CachedViewModelCellFactory has now a shortcut method for use cases where the cell is an mvvmFX-View. For example: CachedViewModelCellFactory.createFxmlView(MyView.class); creates a cellfactory, that loads an MyView for every cel.
• [#303] A new check in the loading mechanism was added. When a View tries to inject a ViewModel with @InjectViewModel we now check that the type of the ViewModel matches the declared generic type of the View.
• [#269] Maven dependencies are now using the maven dependency management feature. Thx to @tomasz for this contribution.
• [#279] For the mvvmfx-cdi module the dependency to org.jboss.weld.se:weld-se was replaced with weld-se-core as weld-se is an uber-jar. This should prevent dependency problems when using other libraries that also have dependencies to weld-se. Thx to @tomasz for this contribution.

Bugfixes

• [#281] The ListTransformation util was firing multiple change events when multiple elements where added. This was leading to problems with FilteredList. Now only one change event is fired.
• [#292] Under some special conditions a new ViewModel instance was created even if an existing instance was provided to the FluentViewLoader.
• [#301] NotificationCenter was throwing a NullPointerException when trying to remove an observer that isn't registered.

Documentation

• [#252] Documentation for the @InjectViewModel annotation in combination with dependency injection frameworks was added in the wiki.
• [#217] All examples are now restructured. The "examples" directory contains 3 big example applications books-example, contacts-example and todomvc-example. Additionally there is a subdirectory "mini-examples" for the smaller examples like the helloworld app.

This is a small release with two fixes for problems introduced with the last version 1.3.0.

• Due to the fix for #240 some users had breaking unit tests because of a "toolkit not initialized" Exception when publish/subscribe of the ViewModel was part of the JUnit test. We are now checking if there is a JavaFX UI thread present or not. If no UI thread is present (f.e. while running JUnit tests), the notifications will be published on the current thread like it was done before. This way we can support easy unit tests and still make sure that at runtime all notifications are published on the UI thread. (#263)
• Additionally we have introduced a NotificationTestHelper that can be used to test notifications. The test helper can even be used for use cases where notifications are send from different threads and it will handle the UI thread accordingly. See the new paragraph in the Wiki for more informations: https://github.com/sialcasa/mvvmFX/wiki/NotificationCenter#testing-notifications
• There was a problem with the getHighestMessage method of the ValidationStatus class introduced with #194. In some cases inside of ChangeListeners on the validProperty or one of the observable lists of validation messages, the getHighestMessage was throwing IndexOutOfBoundExceptions. We have now a new implementation for this method that fixes the problems. (#264)

The biggest feature in this release is the support for validation and an extended support for ResourceBundles.

Validation (BETA) (#194)

Docs: https://github.com/sialcasa/mvvmFX/wiki/Validation

• The user can now use Validators to define validation logic in the ViewModel. In the View there are ValidationVisualizers used to show validation results from the ViewModel in the View. This way the validation logic is separated from UI code and can be tested.
• There are 3 validator variants at the moment: FunctionBasedValidator, ObservableRuleBasedValidator and CompositeValidator
• An implementation of a ValidationVisualizer is provided that uses the third-party library "ControlsFX" for decoration.

ResourceBundle handling

Docs: https://github.com/sialcasa/mvvmFX/wiki/resource-bundles-i18n

• define a global resourceBundle (#234)
• support resource bundles for sub views via fx:include (#235)

In both cases there is a hierarchy of the bundles so that values from the global resourceBundle are overwritten (if they share the same key) by values from the per-view bundle (the one that is provided to the FluentViewLoader) and these again are overwritten by bundles for fx:included FXML files.

ModelWrapper now has "dirty" and "different" flag (#232)

• dirtyProperty indicates whether a change was done to at least one of the properties of the ModelWrapper instance
• differentProperty indicates whether the values of the properties of the ModelWrapper are different to the wrapped model instance. In contrast to the dirtyProperty this flag will switch back to false when the user changes the property value back to the value of the model object.

Bugfixes

• In contrast to the statements in the JavaDoc a notification published directly from the ViewModel wasn't delivered on the UI thread in any case. (#240)

This is a hotfix release

• #237 Update dependency versions of CDI and Weld.

This release mainly contains improvements for the beta features ModelWrapper and Commands that where added in the last release. Additionally there are changed for the Notifications mechanism.

Commands (BETA)

Docs: https://github.com/sialcasa/mvvmFX/wiki/Commands

• The Command interface now has a progress property that is similar to the progress property of JavaFX's Task class. The DelegateCommand is now implemented as a subclass of Service. Instead of a 'Runnable' it now takes a 'Supplier' as argument where Action is a subclass of Task<Void>. (#218 and #225)
• The 'Command' has now a property 'notExecutable' which is the negated version of 'executable'. This way binding to the 'disable' property of a Button is easier. (#210)

ModelWrapper (BETA)

Docs: https://github.com/sialcasa/mvvmFX/wiki/ModelWrapper

• In version 1.1.0 the ModelWrapper was creating fields of type Property<String>, Property<Integer>, Property<Number> and so on. This makes databinding complicated. In the new release the created type ìs StringProperty and IntegerProperty etc. which will simplify data binding a lot. (#211)

Notifications

Docs: https://github.com/sialcasa/mvvmFX/wiki/NotificationCenter

• It is now possible to send notifications directly from the ViewModel to the corresponding View without using the global NotificationCenter. (#203)
• A bug was fixed where an observer was still registered after unsubscribe when the same observer instance was subscribed multiple times. (#223)

New Features

Commands (BETA) (#193)

You can now use Commands to encapsulate actions in the ViewModel and connect them to the View. Each Command has a running and isExecutable property that can be used for bindings in the View. See this wiki page for a detailed description.

Mapping between Model and ViewModel (BETA) (#199)

For CRUD like applications there is now a ModelWrapper that can be used to map between the ViewModel and the Model. This way the developer can reduce the coupling between ViewModel and Model and reduce some code needed to copy values between both. See this wiki page for a detailed description.

CachedViewModelCellFactory (#179)

The new CachedViewModelCellFactory can be used to show mvvmFX Views as items in a ListView. The control of what views are visible is done by providing an observable list of ViewModels. See this wiki page for a detailed description.

initialize life cycle method for ViewModels (#185)

ViewModels can now have a life cycle method initialize too that will be automatically invoked when the ViewModel instance was fully injected. Please Note: This is an API breaking change. If your ViewModel already has a method with the signature public void initialize() this method will now be invoked automatically by the framework. This can be prevented by renaming the method.

ResourceBundle can be injected into the ViewModel (#176)

The ResourceBundle (if any was defined) can now be injected into the ViewModel too. For this purpose we have added the annotation @InjectResourceBundle. To use the injected ResourceBundle you can use the new initialize method (#185).

Testing Utils for public usage

We had some small testing utils for internal usage for some time that are now available for public via the new module mvvmfx-testing-utils. This includes a class for testing of garbage collection.

<dependency>
    <groupId>de.saxsys</groupId>
    <artifactId>mvvmfx-testing-utils</artifactId>
    <version>1.1.0</version>
    <scope>test</scope>
</dependency>

Some utils are moved into a new sub module

We have moved some of the utilities that where part of mvvmFX-core into a new module mvvmfx-utils. This regards to the SizeBindingBuilder and the ListenerManager that where not directly related to MVVM.

The classes have still the same package which means that the user only needs to add the new module to the projects Maven POM.xml. There are not changed in the code needed.

<dependency>
    <groupId>de.saxsys</groupId>
    <artifactId>mvvmfx-utils</artifactId>
    <version>1.1.0</version>
</dependency>

Bugfixes

Two ViewModel instances where created under some conditions (#181)

When no field for the ViewModel was defined in the View there where two instances of the ViewModel created even if only one would be needed and expected.

This release is the first stable release of mvvmFX.

Changes

#153 Change artifact id's to lower-case In the past the artifact id was "mvvmFX". Now it is "mvvmfx" in all lowercase. When you like to switch from an old version to the new one you have to adjust the maven dependency to:

<dependency>
        <groupId>de.saxsys</groupId>
        <artifactId>mvvmfx</artifactId>
        <version>1.0.0</version>
</dependency>

#163 Adjust naming of methods in the NotificationCenter The method names of the NotifiacationCenter were changed to match the conventions of existing publish/substribe systems:

• "addObserverForName" -> "subscribe"
• "removeObserverForName" -> "unsubscribe"
• "postNotification" -> "publish"

Bug fixes

#156 NullPointerException when FxmlView is located in the default package When an fxml based view was not located in a specific package meaning it's in the "default package", an NPE was thrown when the view was loaded.

#124 multiple instantiation of injected classes in mvvmfx-guice Due to a bug in the underlying framework fx-guice in some situations multiple instances of classes were created even if only a single instantiation was expected.

This release has a focus on the Guice and CDI modules. The goal was to stabilize the API for these extension modules.

New Features

#136 The CDI and Guice modules now have a unified API. In both variants the user now can use the three methods initMvvmfx(), startMvvmfx(Stage stage) and stopMvvmfx() to implement the application bootstrapping and shutdown. The standard methods from javafx.application.Application (init(), start(Stage stage) and stop()) can't be used anymore as they are now final in both modules.

#130 The primary stage can now be injected in Guice/CDI applications out of the box. This can be useful for example when you like to create modal windows and dialogs.

#128 The application parameters that are passed into the main application are now injectable in Guice/CDI applications.

#50 There is now a maven archetype that can be used to setup new mvvmfx-based applications.

API breaking changes

#136 The init, start and stop method signature for the CDI/Guice modules have changed (see above for a detailed explanation).

#142 ViewListCellFactory is now a functional interface and not an abstract class anymore. This way it is possible to use a lambda expression. In most use-cases this change won't break existing code because anonymous inner classes still work. Only when you have extended from the abstract class ViewListCellFactory the code will break. Instead you have to implement the interface now.

#132 In version 0.3.0 the ViewLoader was marked as deprecated. In this version the class was removed. Use the FluentViewLoader instead.

#117 The class ListTransformation is now matching the JavaFX bean conventions.

Minor changes

#127 In guice applications the method initGuiceModules is now optional. Old code using this method is still working. The only difference is that with the new version you aren't forced to override this method if you don't want to define own guice modules.

New Features

#88 Support for JDK 7 was removed. We are now only supporting Java 8.

#82 We now have a fluent API to load views with the FluentViewLoader. The old ViewLoader was marked as deprecated and will be removed in version 0.4.0. because it would be to much work to provide overloaded methods for every combination of parameters.

#78 The viewModel is now available in the ViewTuple. In conjunction with this we are now creating a viewModel instance every time a view is loaded even if there is no viewModel referenced in the view itself (#109).

#81 It is now possible to (re-)use an existing ViewModel instance when loading a View.

API breaking changes

#65 Package structure was changed to archive a clean and simple API. All classes, interfaces and annotations that are used to load views are now located in the package de.saxsys.mvvmfx. Utilities like the ListenerManager or SizeBindingsBuilder are located in subpackages under de.saxsys.mvvmfx.utils.

#73 Instead of only logging errors now Exceptions are thrown in many cases. (#83, #97)

#80 in the ViewLoader the method setController was renamed to setCodeBehind to better reflect the meaning of the parameter. Additionally the type of the param is now the generic ViewType instead of Object.

#88 Java7 support was removed.

Minor changes

#85 Dependency to Google Guava was removed.

#99 HostServices is now injectable in CDI/Guice based applications.

• Views are now created by implementing either FxmlView or JavaView interfaces instead of extending the abstract View class
• Views can be implemented in Java with the new interface JavaView and in FXML with the interface FxmlView
• Interfaces, Classes and Annotations that are meant to be public API for the core functionality of the framework are now moved to the package de.saxsys.jxf.mvvm.api. These are:
  • FxmlView
  • JavaView
  • ViewModel
  • InjectViewModel
  • MvvmFX
• ViewModels are injected with the @InjectViewModel annotation instead of the old getViewModel() method.
• ViewTuple has now generic types for both the View and the ViewModel. This way the user can access the view (code-behind) without casting.
• ListTransformation util class to bind observable lists with different types to each other. (thanks to @mthiele)
• The SizeBinding utils class is deprecated. Instead there is a new SizeBindingsBuilder class that provides a fluent API to bind or unbind the size, width or height of components.

• cleaned up SLF4J dependencies
• Removed generic type resolution with library "TypeTools"
• #54 fixed javax.inject dependency for guice module

Profiles for Java 7 and Java 8

Fixed hard error on Pom

• MVVM Base Classes + MVVM Tooling Classes
• EventBus (NotificationCenter)
• ListenerManager (Avoid memory leaks)
• SizeBindings (Convenient binding of sizes of nodes)
• optional DI support (WELD / GUICE)