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.