Wednesday, October 26, 2016

Drombler FX: Version 0.8 released

I recently released v0.8 of Drombler FX - the modular application framework for JavaFX.

This version comes with two new major features: Single Instance Application and an initial version of a Data Framework which integrates with the Docking Framework.

Single Instance Application

Single Instance Application is an optional feature, which ensures that there is only one instance of your application running, even if the user starts the application several times.

This feature is provided out-of-the-box. It is disabled by default, however, but can be enabled by simply specifying the defaultSingleInstancePort property of the Drombler FX Maven Plugin.



If this feature is enabled and one instance is aleady running, each other application start will pass all its unnamed parameters to the first instance and shuts itself then down. Drombler FX will register a new instance of AdditionalArgumentsProvider for every application start notification.

Read more about Single Instance Application in the new tutorial trail.

Data Framework

This version introduces an initial version of a Data Framework which integrates with the Docking Framework.

At the core of the Data Framework is the concept of Data Handlers. A Data Handler wraps an instance of a particular kind of data and usually knows how to read, save etc. this particular kind of data.

To register a Data Handler for a business object, which e.g. has been obtained from a web service call, use the @BusinessObjectHandler annotation:



To register a Data Handler for a document use the @DocumentHandler annotation:


To associate some file extensions with a MIME type you can register the file extensions using the @FileExtension annotation:



Read more about the Data Framework in the new tutorial trail.

Docking Framework changes and enhancements

This version comes with some changes and several enhancements of the Docking Framework, especially also to integrate the Docking Framework with the newly introduced Data Framework.

One of the biggest changes is how you register and open an Editor:

A Dockable Pane can still be registered as an Editor by using the @EditorDocking annotation, but this annotation now specifies the contentType:



The annotated Editor is required to have a constructor with a single parameter of type contentType().

This contentType is usually a Data Handler registered either with @BusinessObjectHandler or with @DocumentHandler. The icon of the Data Handler will be used in the tabs of the Editors. You also don't specify the Docking Area for Editors anymore.

The standard "center" Docking Area has been renamed to "editor" and is the default Docking Area for Editors if you're using the standard Docking Areas.

There are several ways to open an Editor for a Data Handler:
Apart from the integration with the Data Framework, the Docking Framework comes with the following enhancements:
  • If the framework detects that there's already an Editor open for the provided content, the existing Editor gets selected rather than a new one opened.
     
  • If you close an unsaved Editor or if you close the window/ application while there are still unsaved Editors open, the Docking Framework detects this and provides an according dialog.


Putting all together

The enhancements provided by the Data Framework, Docking Framework and Single Instance Application support allow you for instance to create Single Instance Applications where the user can pass a file path argument to the application and the according Editor will be opened/ selected in the first (single) instance of the application.

Please note that several packages have changed.

Several refactorings have been done, which moved classes to different packages.
If a class isn't found anymore try to delete the import statement and re-import the class again using your IDE of choice. Also have a look at the available Maven Coordinates by following the links in the table below and have a look at the provided sample application.

Concluding remarks

You can find the complete list of fixed issues here: https://github.com/Drombler/drombler-fx/issues?q=milestone%3A0.8


There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps.


The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
  


Name Modules
(incl. Maven Coordinates)
Javadoc Description
Drombler FX Modules Javadoc Drombler FX, the modular application framework for JavaFX based on:
Drombler ACP Modules Javadoc Drombler Abstract Client Platform (ACP) is an abstract, GUI-toolkit agnostic, modular Rich Client Platform based on:
Drombler Commons Modules Javadoc Drombler Commons is a collection of reusable libraries and frameworks. They ship with OSGi meta data but don't require an OSGi environment.


If you find issues or have enhancement requests, you can file a ticket here: https://github.com/Drombler/drombler-fx/issues.

Saturday, September 17, 2016

News from the Software Smithy: Version 0.6 released

SoftSmithy news: I recently released a new version of the SoftSmithy Utility Library and the SoftSmithy Development Utility Library.

It has been a while since the last release but a lot of work has been undertaken.

SoftSmithy moved from SourceForge.net to GitHub.
This includes:
  • You can find all SoftSmithy repositories on the SoftSmithy GitHub organization site.
  • All SoftSmithy repositories have been migrated from Mercurial to Git
  • The Gitflow has been configured for all repositories. You can find the current development in the develop branches (default branch) and the released versions in the master branch.
  • The static pages as well as the Wiki pages haven been migrated to GitHub Pages.
Java SE 8
All modules require now at least Java SE 8.

In addition some small additions, fixes and clean-ups have been added.
Note that for easier version management the version of the SoftSmithy Development Utility Library is aligned with the version of the SoftSmithy Utility Library. As the SoftSmithy Development Utility Library has a dependency on the SoftSmithy Utility Library it's recommended to use the same version of both libraries until the APIs are stable!

You can find the lates Javadoc here: Javadoc

I deployed the artifacts (including the source and javadoc artifacts) to Maven Central.

Monday, November 23, 2015

Drombler FX: Version 0.7 released

I recently released v0.7 of Drombler FX - the modular application framework for JavaFX.

It has been a while since the last release but a lot of work has been undertaken.

Drombler moved from SourceForge.net to GitHub.
This includes:
  • You can find all Drombler repositories on the Drombler GitHub organization site.
  • All Drombler repositories have been migrated from Mercurial to Git
  • The Gitflow has been configured for all repositories. You can find the current development in the develop branches (default branch) and the released versions in the master branch.
  • The static pages as well as the Wiki pages haven been migrated to GitHub Pages.
  • The tutorial has been migrated from the Wiki pages to Asciidoc files which are also published to the GitHub Pages. The Asciidoc files allow to
    • compile the included samples first, to make sure the correct version of the API is used and that there is no typo
    • keep different versions of the tutorial for different releases
    • publish the tutorial in different formats
    • easily style the tutorial 
  • The issues have been migrated to the issue system provided by GitHub.

Experiments with CDI & OSGi

A lot of work has been done in experiments to integrate CDI and OSGi.

Unfortunately, among several issues
  • the fact that at the time of writing the specification how CDI should work in an OSGi environment is still not final yet
  • the major difference between the dynamic nature of OSGi services and the static nature of CDI bean discovery at startup, which are hard to overcome
  • issues when trying to integrate CDI providers with OSGi Dynamic Services
put an end to these experiments for now.

Please join the discussion here how CDI still could be integrated into a future version of Drombler FX.

Dockable selection notification

There are now 2 new method-level annotations: @Select and @Deselect.

The annotated methods get called, if present, when the currently selected Dockable (eg. represented as a Tab) of a Docking Area (eg. represented as a TabPane) changes.

(Every non-empty Docking Area has one selected Dockable - the one which is visible.)

 

Modified Dockables

FXDockableData has a new modified-property to indicate if the data represented by the Dockable has been modified.

The behavior of the default skin is to add/ remove the CSS style class "dockable-modified" to/ from the tab representing the Dockable whenever this flag changes.

The default CSS changes the tab font to bold.

The DockableDataModifiedManager listens for Savable in the local contexts of the Dockables and synchronizes the modified-property of FXDockableData accordingly.

Drombler FX configures this manager out-of-the-box.

The effect is that whenever you add a Savable to the local context of a Dockable, the font of the tab will change to bold indicating that the content of the tab has changed and hasn't been saved yet. Since the "Save" action and the "Save All" actions also listen for Savable in the active/ application context, they get enabled accordingly. When you click on one of these save buttons/ menu items, then they call the according save method of the Savable, which should remove itself from the local context again and thus disable the save actions and changing the tab font back to default.

All this works in a loosely coupled way thanks to the Context Framework. All you have to do is to add/ remove the Savable to/ from the local context of the Dockable.

To inform the application framework that the Dockable provides a local context, the Dockable needs to implement the LocalContextProvider interface eg. by using a SimpleContext.

The save method of the Savable then can be implemented to store the content to a file, to a DB, call an EJB or a webservice, send a JMS message or whatever your application has to do for this kind of data.

Pluggable application layout

The application layout is now pluggable!

Add the following dependency to use a classic desktop application layout with a menubar, a toolbar and a content area as the content of the JavaFX application.

You can replace this dependency with your own implementation of MainSceneRootProvider, which needs to be registered as an OSGi service.

By providing your own implementation you can make your application look completely different.

Please note that the content of the content area of the default application layout is pluggable, too!

Add the following dependency to use the Docking Framework for the content area.


This dependency also configures the Docking Framework to integrate with the Context Framework.

You can replace this dependency with your own implementation of ApplicationContentProvider, which needs to be registered as an OSGi service.

By providing your own implementation you can make the content area look completely different while keeping the classic desktop application layout, which uses the Action Framework to register menu items and toolbar buttons with annotations.

Please note that several packages have changed.

Several refactorings have been done, which moved classes to different packages.
If a class isn't found anymore try to delete the import statement and re-import the class again using your IDE of choice. Also have a look at the available Maven Coordinates by following the links in the table below.


Concluding remarks

You can find the complete list of fixed issues here: https://github.com/Drombler/drombler-fx/issues?q=milestone%3A0.7


There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps.


The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
  


Name Modules
(incl. Maven Coordinates)
Javadoc Description
Drombler FX Modules Javadoc Drombler FX, the modular application framework for JavaFX based on:
Drombler ACP Modules Javadoc Drombler Abstract Client Platform (ACP) is an abstract, GUI-toolkit agnostic, modular Rich Client Platform based on:
Drombler Commons Modules Javadoc Drombler Commons is a collection of reusable libraries and frameworks. They ship with OSGi meta data but don't require an OSGi environment.


If you find issues or have enhancement requests, you can file a ticket here: https://github.com/Drombler/drombler-fx/issues.

Sunday, March 22, 2015

Drombler Commons: Conventions to simplify FXML loading

Correctly loading a FXML file in JavaFX usually requires quite some boilerplate code.

In my projects I came up with a new naming convention:

If a class "mypackage.<name>" loads a FXML file, then the FXML file should be in the same package and be named "<name>.fxml".


One advantage is, that when following this naming convention it's quite easy to see, which FXML loader/ fx:root-controller and FXML file belong together.

Another advantage is, that when using a utility method, the loading code for eg. a fx:root-based mypackage/MyPane.fxml file (a construct I can highly recommend) such as:


can be simplified to this:


This code will:
  • set the ClassLoader
  • set the root
  • set the controller
  • set the ResourceBundle by looking for a mypackage/MyPane.properties file (or a locale specific derivation using the default Locale)
  • set the location to mypackage/MyPane.fxml
  • load the mypackage/MyPane.fxml file
  • reduce code duplication 
  • reduce typos

The FXMLLoaders utility class provides several other utility methods taking advantage of this naming convention, such as utility methods for loading non-fx:root based FXML files, which then for a mypackage/MyApplication.fxml file such as:


can simplify the loading code to this:


Other variants allow to specify an alternative ResourceBundle or a pre-existing FXMLLoader.

The FXMLLoaders utility class is provided by the Drombler Commons - FX - Core artifact:


Like the other Drombler Commons artifacts, it can be used inside and outside of an OSGi environment.

Saturday, February 28, 2015

Drombler FX: Version 0.6 released

I recently released Drombler FX v0.6. Drombler FX is a modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first).

This is mainly a bug fix release.

You can find the complete list of fixed issues here: http://issues.drombler.org/milestone/0.6

Please note that there is currently a critical bug in the Docking Framework because of a bug in JavaFX. That bug should be fixed in the Java SE/ JavaFX 8u40 release however (expected release date: March 2015).

There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps.

Drombler FX uses Apache Felix as its OSGi container by default.
As an application framework it makes sure JavaFX and OSGi will get started properly and it provides the main window.


The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
  


Name Modules
(incl. Maven Coordinates)
Javadoc Description
Drombler FX Modules Javadoc Drombler FX is a modular Rich Client Platform for JavaFX based on:
Drombler ACP Modules Javadoc Drombler Abstract Client Platform (ACP) is an abstract, GUI-toolkit agnostic, modular Rich Client Platform based on:
Drombler Commons Modules Javadoc Drombler Commons is a collection of reusable libraries and frameworks. They ship with OSGi meta data but don't require an OSGi environment.

You can use the Drombler Forum for questions and discussions.

If you find issues or have enhancement requests, you can file a ticket here: http://issues.drombler.org.

Friday, February 27, 2015

News from the Software Smithy: Version 0.5 released

SoftSmithy news: I recently released a new version of the SoftSmithy Utility Library and the SoftSmithy Development Utility Library.

In addition to some small additions, fixes and clean-ups, SLF4J is now being used for logging (new dependency).
Note that for easier version management the version of the SoftSmithy Development Utility Library is aligned with the version of the SoftSmithy Utility Library. As the SoftSmithy Development Utility Library has a dependency on the SoftSmithy Utility Library it's recommended to use the same version of both libraries until the APIs are stable!

You can download the archives (including the jars, documentation, samples etc.) and read more about the changes here:
SoftSmithy Utility Library v0.5 (online documenation)
SoftSmithy Development Utility Library v0.5 (online documentation)

I deployed the artifacts (including the source and javadoc artifacts) to Maven Central.

Sunday, December 21, 2014

Using ControlsFX in a Drombler FX application

Earlier this year I've contributed a patch to ControlsFX to provide OSGi meta data in the Manifest file.

This patch allows ControlsFX to be used more or less out-of-the-box in an OSGi environment such as Drombler FX.

I'm writing "more or less out-of-the-box" since you still need an additional configuration in a Drombler FX application to be able to use ControlsFX.

The latest Drombler FX release provides some documentation in the sample generated by the Drombler FX Maven Archetype about this additional configuration.

You can find this in the generated test-application project in the file src/main/app/conf/config.properties.

You basically have to uncomment some lines there, which looks then like this:


The reason you need this additional configuration is that ControlsFX uses some non-published, internal JavaFX implementation classes and the OSGi environment with the configuration provided by Drombler FX is hiding these classes by default. Adding the necessary packages to org.osgi.framework.system.packages.extra allows ControlsFX to use these classes as well.

Note however that with this configuration these packages are available not only to ControlsFX but to any OSGi bundle in the application. Generally it's strongly discouraged to rely on non-published internal classes as they can change even with any minor release. Backwards compatibility is not maintained for these classes! Using this configuration the OSGi environment cannot protect your own OSGi bundles from using the classes of these packages.

The configuration has been tested with org.controlsfx:controlsfx:8.0.6 and org.controlsfx:controlsfx:8.0.6_20.