Today we have released the version 1.7.0. The details of the release can be found in the github release notes.

Today we have released the version 1.4.0. This release contains mostly improvements for existing features and bugfixes. The details of the release can be found in the github release notes.

The ModelWrapper now supports the mapping of Lists. In the future we will further work on the ModelWrapper to support more complex models and other collections.

Another noteworthy improvement is the possibility to exchange the implementation of the NotificationCenter. A nice use case for this is to use a mock implementation of the NotificationCenter in unit tests.

Today we have released a hotfix version 1.3.1. In this release we are fixed two minor problems introduced in the last release 1.3.0. The first problem was a testability issue due to thread handling of the publish/subscribe mechanism of ViewModels. This was made simpler and a new NotificationTestHelper was introduced.

The second problem was an IndexOutOfBoundException when using the getHighestMessage method of the ValidationStatus class inside of ChangeListeners on the validProperty or one of the observable lists of messages.

See the release notes for more details.

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.

The new version “1.2.0” of mvvmFX was released.

We have received lots of feedback for the new beta features of our last release, especially for the ModelWrapper and the Commands. Therefore this release mainly contains improvements for these two features.

Commands

• The Command interface now has a progress property 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`.

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

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 type ìs StringProperty and IntegerProperty etc. which will simplify data binding a lot.

Notifications

• It is now possible to send notifications directly from the ViewModel to the corresponding View without using the global NotificationCenter.

• A bug was fixed where an observer was still registered after unsubscribe when the same observer instance was subscribed multiple times.

Today we have released the new version 1.1.0 of mvvmFX.

This time we have lots of new features added to the framework:

Commands

The most interesting new feature are the Commands. With them you can now encapsulate actions in the ViewModel and provide them to the View. Each Command has boolean properties showing if it is running at the moment and if it isExecutable. The latter can for example be used in the View to bind the visibility of a button. With CompositeCommands you can compose many commands so that all sub-commands are executed when the composite command is triggered. See the wiki page for a detailed explanation.

ModelWrapper

The second big feature is the ModelWrapper. This class can simplify the mapping between the Model and the ViewModel for CRUD like applications. Instead of duplicating the fields of a model class in the ViewModel you can now use the ModelWrapper that support reloading (copy values from Model to ViewModel), resetting (set ViewModel to default values) and committing (copy values from ViewModel to Model). In the wiki you can see a detailed example.

Others

Other interesting features are the possibility to inject the ResourceBundle into the ViewModel, a CellFactory that simplifies the usage of mvvmFX views as items in a ListView.

Utility modules

Additionally we have introduced two more Maven modules: mvvmfx-utils contains utilities that are not directly related to MVVM but that are more generally useful for JavaFX development. We moved the SizeBindingsBuilder and the ListenerManager from the core module to this new module to improve the cohesion of the core module.

mvvmfx-testing-utils contains utils that we used for testing purposes internally for some time. Now these utils are available for the public. The most interesting is the GCVerifier that we are using for testing situations where Garbage Collection is important.

See the whole list of changes at github: https://github.com/sialcasa/mvvmFX/releases/tag/mvvmfx-1.1.0

This week we have released the new version 1.0.0 of mvvmFX.

With the change to version 1.0.0 we like to express our opinion that the library is finally ready for production. It was a big desire over the last few releases to stabilize the API and improve the documentation and examples.

Changes

There is only a limited number of changes this time.

Most notable is the change of the Maven artifact id. In the past we have used the artifact id “mvvmFX” (note uppercase “FX”) which of course is wrong due to the maven naming guidelines. Now all artifact id’s are lowercase. To use mvvmFX you now have to use this dependency definition:

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

The second change is the renaming of method names of the NotificationCenter to match typical naming conventions for publish/subscribe systems. This is an API-breaking change but we think that it improves the usability of the class a lot.

Bugfixes

There are two bug fixes in this release. The first was NullPointerException for the case that an FxmlView was placed in the default package.

The second bug was a problem with multiple instantiations of injected classes when using the Guice module.

You can see the full changelog at the release section of github.

Future

With the first stable release finished now we can work on more advanced features again. In the future we will take care of features that are needed for bigger applications. The first thing will be the support for Scopes to be able to build groups of related views.

Today we have released the new version 0.4.0 of mvvmFX.

This time the focus was on the extension modules for Guice and CDI. We have done a lot of work to unify the API of both modules so that it’s easier to switch between these dependency injection frameworks.

Additionally you are now able to inject more JavaFX stuff into your components out of the box, i.e. the application parameters that were passed into the app or the primary stage. This way it’s easier to create modal windows in your application: Simply inject the primary stage and set it as parent in your View.

Another big point on the list was to create a more extensive example application to show the usage of mvvmFX. We have created a Contacts-App that also integrates other community libraries and frameworks like DataFX, ControlsFX, Advanced-Bindings, AssertJ-JavaFX and fontawesomeFX.

The contacts app is based on our CDI module. We have used CDI events to trigger the dialogs and other actions.

Now there is a maven archetype available that can be used to setup a new mvvmfx-based application in seconds.

You can see the full changelog at the release section of github.

We are very proud to announce the release of the new version 0.3.0 of mvvmFX.

We have a bunch of interesting changes and new features. The most notable feature is probably the new FluentViewLoader. This is a fluent API that can be used to load views instead of using the overloaded methods of the old ViewLoader.

With this version we have dropped the support for Java 7. This makes the development of the framework easier because we can profit from the new features of Java 8 like Lambdas. We think that most modern JavaFX projects will use Java 8 anyway and most of the other useful frameworks like ControlsFX are requiring Java 8 too.

There are some API-breaking changes too. First of all we have moved our main classes and interfaces that are needed to load Views into the package de.saxsys.mvvmfx. At the moment our framework is still in a beta state and therefore API breaking changes are possible. But we are looking forward to stabilize the API in the future.

You can see the full changelog at the release section of github.

Since last week we are using the cloud continuous integration service Travic-CI to build the mvvmFX code on every commit pushed to github. This makes working on the project more comfortable because we get an instant feedback when changes are made and new pull requests are created.

Here you can view the current state of the build online: https://travis-ci.org/sialcasa/mvvmFX

Additionally we have configured the build so that a new SNAPSHOT is deployed to the Sonatype OSS maven repository on every commit that arrives on the development branch of the project. This way new features can be tested very quickly by our users.

Today we present you our new project page for mvvmFX.

On this page we will inform you about new releases and other interesting news.

Additionally you can find here tutorials, examples and the documentation.