Adding JavaFX Properties to a DTO

Now that I have understood what a DTO is good for, I’m thinking about ways to improve it. As they are right now, our DTOs are POJOs extended by JSR 303 annotations for defining constraints on their fields/methods. The annotations are duplicates of the annotations defined on the corresponding entities.

Since I have worked with the UI code most of my time so far, I have felt the drawback of not having JavaFX properties in our DTOs: they cannot be observed easily by the GUI controls. There is a wrapping mechanism to add this observability, but it is rather complicated to use and requires a lot of extra code.

So why not make the DTOs full JavaFX beans? After all, we would not be the first project to do this. Two common objections were raised when I brought this up:

  1. DTOs are created on the server which should not have dependencies to a GUI/client technology.
  2. We would need to mix JavaFX beans with JSR 303 annotations.

Let’s address the first point. Yes, having a GUI dependency in your server code is not a good idea. But are JavaFX properties a GUI technology? Or even a client technology? It’s a bit unfortunate that they were introduced as part of JavaFX in a javafx.* package such that everyone identifies them as a GUI technology at first sight. It’s an image problem. I would argue they are a self-contained technology which is independent of any GUI parts of JavaFX and could therefore be used for any data model, no matter if it’s on the client, on the server, or shared between both. Even if one does not use JavaFX for the frontend, depending on JavaFX properties would do almost no harm in practice since JavaFX is part of the JDK and your server code certainly depends on the JDK. So the no client dependencies on the server argument is merely a formal one in my opinion.

What about the second point, mixing JavaFX properties with bean validation annotations? I have never tried it myself, but I have the feeling it cannot be that big of a problem. If it works in the FXForm2 demo, why should there be a fundamental incompatibility between these two technologies? But I admit that a good prototype is needed to make a final judgment.

We will have a meeting on this tomorrow. Let’s see what the others think.

 

Using FXForm2 with EMF Models

Based on these considerations from July, we gave FXForm2 a shot for generating forms from EMF models. It worked quite smoothly after we wrote the factories that defined how the custom data types used in our models should be displayed.

We found a few things that are worth noting:

  1. Using Java Bean Validation
    In order to validate our EMF models using the Java Bean Validation API (JSR-303) that comes with FXForm2, we wrote wrapper classes for those model elements that we wanted to add constraints to. We decided to not touch the generated code.
  2. Using another validation implementationFXForm2 can use any implementation of JSR-303. Using the Hibernate implementation is suggested on the FXForm2 website, but we found it easy to supply our own implementation based on EMF’s validation features such as the Diagnostician class.
  3. Validation philosophies
    When you enter an invalid value into a field, FXForm2 won’t update the corresponding model attribute. The value you see in the form differs from the value in the model. The model thus always has a valid state.EMF validation typically works in a different way: you start the validation operation only after all model values were set. This allows for invalid states of the model.
  4. Dynamic beans
    An open issue
    seems to be (as least for us) the handling of a String-to-String Map attribute inside an EMF bean class that stores user-supplied key-value pairs which should be displayed as regular attributes of the bean. Antoine suggested a solution based on a custom control (with a factory and a skin), but it comes with a different visual appearance for the user-defined attributes. This is work in progress.

GUI Generation with JavaFX

Recently, we have had a look at JavaFX libraries for generating UIs in a dynamic way. The idea is that we have a data model (a JavaBean class, an EMF model class, a model class with JavaFX properties,…) as input for some GUI builder that takes the model and generates a matching user interface with bindings between the model and the JavaFX controls. In a perfect world, this library would allow us to use a variety of data models and to customise the generated user interface.

We have had three candidates (all open source). As we use EMF a lot, two of them are based on EMF models.

1. FXForm2

http://dooapp.github.io/FXForm2/

This pops up early when you are looking for UI generation libraries for JavaFX. As the name implies, it is meant for generating forms from model beans.

A sample form generated by FXForm2
Source: https://github.com/dooApp/FXForm2/wiki/Style-your-form-with-css

The main features include:

  • Automatic form generation and binding to bean properties
  • CSS support
  • Bean Validation handling (JSR 303)
  • Fields reordering and filtering
  • Tooltips
  • Localization

It takes three lines to add a generated form to your JavaFX scene graph:

2. EMF Edit for JavaFX

http://tomsondev.bestsolution.at/2012/12/13/emf-edit-support-is-coming-to-javafx-via-efxclipse/

This library has a broader scope than FXForm2 as it can generate an entire RCP application with a sophisticated visual model editor rather than just a couple of form fields. Or you can define your own controls and easily bind your EMF model instances to these controls, including support for drag & drop and undo/redo commands. An example of a user interface based on a “Contacts” model can be seen in Tom’s video from the link above.

A sample application using EMF Edit for JavaFX
Source: http://tomsondev.bestsolution.at/2012/12/13/emf-edit-support-is-coming-to-javafx-via-efxclipse/

3. EMF Client Platform

http://eclipse.org/emfclient/index.html

This takes the idea of EMF Edit one step further. As the ECP website says:

The goal is to provide a one-click application based on a given EMF model. Besides the EMF model, no additional components have to be developed or generated.

A sample application as generated by the EMF Client Platform
Source: http://eclipse.org/emfclient/

So when you have your EMF model, you are only one click away from a complete client application with a model explorer, an editor, a persistence mechanism, and a couple of other nice things. The editor for the model attributes is similar to the data form generated by FXForm2, but it is embedded in an entire application whose pieces are customisable and extensible.

The bad news is that there is currently no JavaFX support for ECP.
[Update]
As Tom Schindl has pointed out in the comments section, there is a first version of JavaFX support for ECP in one of the development branches of the e(fx)clipse project. See here.

4. Summary

We have not found the perfect solution yet. FXForm2 has a promising approach for easily generating forms, of which we are going to have a lot in our final product. It requires some tweaks to make it work with EMF models but that is a small obstacle. What worries me a bit is the maturity of this library: the latest version is 0.2.2. So is it ready for production use? Well, there’s at least one real-world application that uses it.

EMF Edit is a very powerful framework but does not generate controls on the granularity we require for most parts of our application. It will certainly be of use for fancy features like drag & drop and the command stack. Maybe we can combine its strengths with the power of FXForm2 for generating really rich forms.

The EMF Client platform has a very appealing one-click approach but it lacks support for JavaFX. Once this limitation is gone, we may give it another look. A major question will then be how far we can customise the basic layout of the generated application which by default is very different from what we have in mind for our user interface.