1.2.0

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)

1.1.0

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.

1.0.0

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.

0.4.0

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.

0.3.0

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.

0.2.0

• 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.

0.1.4

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

0.1.3

Profiles for Java 7 and Java 8

0.1.2

Fixed hard error on Pom

0.1.1

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