jeudi 28 novembre 2013

FXForm: two releases and a lot of new features

We have added a bunch of cool features to FXForm, let's have a look!

Get ready for JavaFX 8

FXForm is now ready for JavaFX 8. We have adopted the following versioning conventions:

  • FXForm 2.2.x for JavaFX 2.2 (latest version: 2.2.4)
  • FXForm 8.0.x for JavaFX 8.0 (latest version: 8.0.1)
The version 8.0 of FXForm comes with the support of new types: LocalDate and Color using the new DatePicker and ColorPicker controls.


Improved data validation

We have improved the data validation layer of FXForm by adding the support of class level constraint and a finer granularity in constraint handling.

Class level constraint validation

FXForm now support class level constraints. This can be used to specify cross-field constraints.
The class level constraint violations are reported in the form. See below an example with the validation of a repeat password field:


In this case, our bean was simply annotated with the @PasswordMatch annotation which is a custom constraint validating that both password fields are equals. See Creating custom constraints for more informations about this.

Strict constraint versus warning constraint


Sometimes you want a constraint to be strict, sometimes you want it to be just a warning. FXForms allows you to specify this in your constraint declaration by using the group attribute of the constraint. By default a constraint is considered as strict. If you want your constraint to be a warning, use the Warning group provided by FXForm: 


In this case the @Max constraint will be treated as a warning. The main difference between a warning and a strict constraint is that with a warning, the model value will be updated even if the user input violates the constraint, which is not the case for as strict constraint.
Elements in the form that violates a constraint get a different style class for strict constraints and warning, so that the user feedback can be different in both cases.


In this example, the element editor is red and its label is bold when a strict constraint is violated and the element editor is orange when a warning is violated.

Multiple bean source

You can now edit multiple beans in the same form using the MultipleSourceBean


All features work as for a simple bean, including filters (reorder, exclude,...) and custom factories.

@Adapter

A custom adapter can now be specified directly on a field using the @Adapter annotation. If specified, FXForm will use the adapter provided by the annotation to bind the field property with the view property. See customizing bindings in FXForm2 for more informations about adapters.

Better handling of bound and read-only properties

FXForm introduces a notion of "editable" on the Node (see FXFormNode) which indicates whether a Node manipulated by FXForm allows the user to provide input.

FXForm now automatically disables editable nodes when bound to a property that is already bound or that is read-only. If the node is not editable (for example a Label), then it remains enabled.

New NodeSkin

FXForm now provides a NodeSkin. This NodeSkin can be used if you want to be responsible for creating the view of your form. You can then give your Node to the NodeSkin and FXForm will lookup for the required nodes and bind them to your bean. The lookup is based on the node ids. See wiki to understand how FXForm does the mapping between bean fields and nodes.

If your view is implemented in FXML, you can still use the FXMLSkin.

ListProperty support

Certainly one of the most funny (and useful!) feature of the latest release. FXForm now creates a TableView for ListProperty fields. Columns are populated automatically by analyzing the generic type of the ListProperty and extracting fields. When you click on a row, a popup shows, with -guess what- an FXForm :) This popup allows the edition of the selected item.



This feature is pretty powerful, since you can now edit pretty much your whole tree of model objects using just an FXForm. We might also add a default support for SetProperty and MapProperty in the future.

You can find the full release notes here. Thanks to usander, peterbecker and pjean for their appreciated feedback on the project.

Have fun with FXForm :)

2 commentaires:

  1. Congratulations for the framework.

    I'm using a FXMLSkin to bind a FXML to the properties of a bean by using the -form-editor suffix.

    How can I bind a TableView to a ListProperty of that bean and how should be the columns named?

    Thank you,
    David

    RépondreSupprimer
  2. David,

    Thanks for your interest. Could you post your question to github as this might help other users?

    Actually, the TableView item list should be bound automatically to your ListProperty field if the id of the TableView has been set correctly according the your field name (for example if your field is called myList, the TableView should have the "myList-form-editor" id) .

    The columns are named after the name of the fields of tthe list items class.

    The TableViewFactory could be improved to support customization of the columns names.

    RépondreSupprimer