Tutoriel sur les propriétés en JavaFX

De l'art et de la manière de définir des propriétés dans vos objets JavaFX

Fabrice Bouyé

Cet article a pour but de vous expliquer comment définir et utiliser des propriétés JavaFX. Cet article fera un rapide tour d'horizon des différents types de propriétés définies dans l'API en montrant quelques cas particuliers d'utilisation où le programmeur doit faire attention à ce qu'il manipule. Cet article n'abordera pas le binding.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum Commentez ♪

- Titre : Tutoriel sur les propriétés en JavaFX

- Auteur : Fabrice Bouyé

- Parution : 20 mars 2014

- Mise à jour : 5 février 2015

- Public visé :

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2013 Fabrice BouyÃ©. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. Conventions

- II-A. Limitation des Java Beans

- II-B. Et en JavaFX?

- III. Les bases

- III-A. Interfaces communes

- III-B. Hiérarchie des classes

- III-C. Écouteurs

- III-C-1. InvalidationListener

- III-C-2. ChangeListener

- III-C-2-a. ChangeListener sur les nombres

- III-D. Threading

- IV. Mise en œuvre

- IV-A. Booléens, littéraux et chaines de caractères

- IV-B. Objets

- IV-B-1. Listes observables

- IV-B-2. Tables observables

- IV-B-3. Ensembles observables

- IV-C. Et les Java Beans ?

- V. Utilisation avancée

- V-A. Propriétés en lecture seule

- V-A-1. Cacher le type réel

- V-A-2. Utiliser des wrappers

- V-A-3. Étendre le type de base

- V-B. Restriction des valeurs

- V-C. Optimisation

- V-C-1. Initialisation différée

- V-C-2. Externalisation des propriétés

- V-C-3. Gestion des liaisons

- V-C-3-a. Classes anonymes

- V-C-3-b. Lambda

- V-C-3-c. Références de méthodes

- V-C-4. Liaisons faibles

- V-C-4-a. Classe anonyme

- V-C-4-b. Lambda

- V-C-4-c. Référence de méthode

- V-D. Empaqueter une valeur d'un POJO

- VI. Conclusion

- VII. Liens

- VIII. Remerciements

I - Introduction

Contrairement à d'autres langages tels que C#, Java ne possède toujours pas une manière implicite de définir une propriété; bien que le format JavaBeans pour déclarer des propriétés dans un objet soit le standard le plus suivi, la définition de propriétés en Java reste encore une affaire de programmation manuelle dans la quasi-majorité des cas. Les années passant, plusieurs projets et JSR ont vu le jour pour faciliter l'écriture et la validation des propriétés, mais, à ce jour, aucun d'entre eux n'a réellement abouti.

Or, au fil du temps, de nouveaux besoins sont apparus tels que la possibilité de faire du binding, c'est-à-dire de pouvoir propager automatiquement la valeur d'une propriété vers d'autres dès sa modification, sans avoir à recoder toute une gestion événementielle manuellement à chaque fois qu'on crée une nouvelle classe. JavaFX 2.x offre désormais un support des propriétés compatible avec les bases de JavaBeans tout en offrant une prise en charge de ces nouvelles fonctionnalités.

Il faut bien comprendre cependant que JavaFX ne règle pas pour autant le problème de la déclaration implicite des propriétés en Java. Cette problématique reste liée à des évolutions futures du langage et de la VM Java.

II - Conventions

Accéder à une propriété nécessite d'appeler une ou deux méthodes qui permettent d'obtenir la valeur de la propriété et de la redéfinir :

- le getter permet de récupérer la valeur de la propriété. Cette méthode n'a pas de paramètres d'entrée ;

- le setter permet de redéfinir la valeur de la propriété. Cette méthode est optionnelle: elle n'est pas présente quand la propriété est en lecture seule. Un setter ne prend qu'un seul paramètre, du même type que celui de la propriété.

Selon la convention, ces méthodes sont écrites sous la forme :

<préfixe><Nom de la propriété avec la première lettre en majuscule>

Pour les getters, on utilisera le préfixe get (verbe anglais signifiant obtenir) pour des valeurs littérales (entiers, flottants, etc.), chaines de caractères ou objet ou is (verbe anglais signifiant être) pour des valeurs booléennes. C'est assez rare, mais parfois certains getters des API Java et JavaFX utilisent le verbe get comme préfixe pour des valeurs booléennes.

Pour les setters on utilisera le préfixe set (verbe anglais signifiant définir).

Ainsi nous aurons :

1. // Propriété enabled.

2. private boolean enabled;

4. // Getter.

5. public boolean isEnabled() {

6. return enabled;

7. }

9. // Setter.

10. public void setEnabled(boolean value) {

11. enabled = value;

12. }

14. // Propriété age.

15. private int age;

17. // Getter.

18. public int getAge() {

19. return age;

20. }

22. // Setter.

23. public void setAge(int value) {

24. age = value;

25. }

27. // Propriété name.

28. private String name;

30. // Getter.

31. public String getName() {

32. return name;

33. }

35. // Setter.

36. public void setName(String value) {

37. name = value;

38. }

39. // Propriété favoriteCar.

40. private Car favoriteCar;

42. // Getter.

43. public Car getFavoriteCar() {

44. return favoriteCar;

45. }

47. // Setter.

48. public void setFavoriteCar(Car value) {

49. favoriteCar = value;

50. }

Les beans offrent donc une notion simple de propriété avec des accesseurs permettant de lire et modifier les valeurs de ces propriétés. Le fait d'avoir une convention de nommage permet d'identifier rapidement les propriétés accessibles dans une classe en lisant sa page de documentation ou en en listant ses méthodes via la reflection (mécanisme d'introspection).

Les propriétés JavaFX restent compatibles avec ces conventions, donc un objet disposant de propriétés JavaFX pourra être utilisé comme un bean normal.

II-A - Limitation des Java Beans

Cependant, il n'est pas vraiment possible de se mettre à l'écoute des changements des valeurs, car ce support est complètement optionnel. Il est en effet possible de rajouter un support des java.bean.PropertyChangeListener sur la classe pour permettre à des listeners (écouteurs) de s'y enregistrer, mais ceci doit être fait à la main pour chaque nouvelle classe créée. Chaque lancement d'événement dans une propriété doit également être codé manuellement.

De plus, il n'est pas du tout possible de faire du binding, c'est-à-dire la capacité de « nouer» aisément des propriétés entre elles pour avoir une propagation automatique des modifications d'une propriété à une autre.

C'est ici que les propriétés JavaFX entrent en jeu: elles apportent une infrastructure prête à l'emploi supportant la propagation d'événements ainsi que le binding.

II-B - Et en JavaFX?

Voici très rapidement ce que donne la propriété age si on l'écrit avec les propriétés JavaFX. Nous entrerons dans les détails des différents types de propriétés dans les sections ultérieures.

1. // Propriété age.

2. private final IntegerProperty age = new SimpleIntegerProperty();

4. // Getter.

5. public final int getAge() {

6. return age.get();

7. }

9. // Setter.

10. public final void setAge(int value) {

11. age.set(value);

12. }

14. // Accès à la propriété.

15. public final IntegerProperty ageProperty() {

16. return age;

17. }

Tout d'abord, on peut voir que, plutôt que de stocker directement la valeur dans la classe, on utilise une propriété JavaFX qui va empaqueter la valeur: il s'agit des classes IntegerProperty et SimpleIntegerProperty. On peut accéder à la valeur de la propriété et la modifier par des accesseurs classiques: get(), getValue(), set(), setValue(). De plus, cette classe se chargera de produire les événements appropriés lorsque la valeur change. Comme cette classe est également une expression, il est possible de faire du binding de haut niveau. L'initialisation de la propriété se fait en appelant une classe concrète SimpleIntegerProperty avec le constructeur par défaut, ce qui mettra la propriété à une valeur par défaut :

- false pour les booléens ;

- 0 pour les nombres ;

- null pour les chaines ou les objets.

Il existe cependant d'autres constructeurs qui permettent de passer une référence au bean parent, un nom textuel à la propriété ainsi qu'une valeur initiale. Pensez à vous référer à la documentation de chaque classe concrète lorsque vous créerez vos propriétés.

Ensuite, nous avons rajouté une 3e méthode en plus du getter et du setter: il s'agit de l'accesseur public à la propriété. Via cette méthode, on peut désormais depuis l'extérieur de la classe, récupérer une référence sur l'objet propriété et rajouter des listeners sur la propriété, faire du binding et aussi directement retirer ou définir la valeur de la propriété via les méthodes set(), get(), setValue() et getValue().

La signature de cette méthode prend toujours la forme :

public final <type de la propriété> <nom de la propriété>Property();

Soit ici :

1. public final IntegerProperty ageProperty() {

2. [...]

3. }

Utiliser cette convention permettra à l'accesseur d'être facilement retrouvé si on use de la reflection.

Enfin, toutes les propriétés et les méthodes sont déclarées final ce qui veut dire qu'elles ne peuvent être ni modifiées, ni surchargées par les classes filles de notre classe. C'est quelque chose de TRÈS important, car cela permet de préserver l'intégrité de la propriété. Si le programmeur pouvait surcharger n'importe laquelle de ces méthodes dans une classe fille, il casserait complètement le mécanisme de la propriété, par exemple en retournant une valeur fixe dans le getter ou en évitant de la stocker dans l'objet propriété dans le setter ou encore en établissant dans le setter une restriction qu'on peut contourner en accédant directement à la propriété. Ainsi, un objet qui accèderait directement à la propriété obtiendrait des valeurs différentes de celles retournées par le getter et le setter… Bref, cela causerait de gros soucis dans le programme, donc mieux vaut ne pas le permettre en interdisant toute surcharge des méthodes.

III - Les bases

JavaFX propose donc toute une série de classes et d'interfaces dédiées à la définition des propriétés qu'elles soient en lecture seule, en lecture-écriture ou encore pour empaqueter des propriétés venant de beans Java normaux ou même des valeurs immutables.

III-A - Interfaces communes

Les interfaces qui sont ancêtres de toutes ces classes sont :

- javafx.beans.Observable - cette interface définit la possibilité d'ajouter et de retirer des écouteurs de type InvalidationListener sur la propriété ;

- javafx.beans.ObservableValue<T> - cette interface définit la possibilité d'ajouter et de retirer des écouteurs de type ChangeListener<T> sur la propriété. Cette interface définit également la méthode getValue() qui permet de récupérer la valeur contenue dans l'objet propriété.

III-B - Hiérarchie des classes

Ces interfaces sont elles-mêmes dérivées en expressions qui contiennent des méthodes destinées à faciliter les expressions liées binding, puis en propriété lecture seule (des classes concrètes où seul le getter est implémenté), et enfin en propriété lecture-écriture avec une implémentation du setter (la méthode setValue()) ainsi que le support du binding et du binding bidirectionnel. Enfin une implémentation concrète prête à l'emploi nous est fournie. Ceci nous donne quelque chose de similaire au schéma suivant, en omettant quelques classes intermédiaires au passage pour les propriétés stockant des valeurs entières :

Figure 1 - Hiérarchie des classes.

Il existe également d'autres interfaces et classes mineures annexes qui rajoutent des méthodes de convenance destinées à faciliter la programmation comme, par exemple ObservableIntegerValue qui définit une méthode get() retournant un int ou WritableIntegerValue qui définit une méthode set() prenant un int en paramètre.

III-C - Écouteurs

III-C-1 - InvalidationListener

Cet écouteur permet d'être tenu au courant des événements d'invalidation des propriétés. En effet, lorsque la valeur d'une propriété change, elle devient invalide. Par la même occasion, elle provoque l'invalidation de toute expression qui lui est liée par binding. L'expression restera invalide tant qu'il n'y a pas d'accès à sa valeur par un getter. Cela veut dire que si la propriété change quand on fait quelque chose comme cela :

JDK7

1. ageProperty().addListener(new InvalidationListener() {

2. @Override

3. public void invalidated(Observable o) {

4. [...]

5. }

6. });

7. setAge(5);             // événement d'invalidation ici.

8. setAge(6);

9. setAge(7);

JDK8

1. ageProperty().addListener((Observable o) -> {

2. [...]

3. });

4. setAge(5);             // événement d'invalidation ici.

5. setAge(6);

6. setAge(7);

On aura bien un événement d'invalidation au premier appel au setter, mais ensuite plus du tout jusqu'au dernier appel au setter. C'est au moment où l'accès au getter se fait que la valeur de la propriété est réévaluée et que la propriété redevient valide. Cela permet de minimiser le nombre d'événements produits et d'empêcher que des propriétés bindées entre elles ne soient réévaluées trop souvent quand cela n'est pas nécessaire.

Attention: si un ChangeListener et un InvalidationListener sont placés sur la même propriété, les événements d'invalidation seront lancés à chaque changement de valeur.

III-C-2 - ChangeListener

Cet écouteur permet d'être tenu au courant des changements de valeur des propriétés. Lorsque la valeur d'une propriété change, la propriété, son ancienne valeur et sa nouvelle valeur sont transmises à l'écouteur pour traitement immédiat.

JDK7

1. ageProperty().addListener(new ChangeListener<Number>() {

2. @Override

3. public void changed(ObservableValue<? extends Number> observable, Number oldValue, Number newValue) {

4. [...]

5. }

6. });

7. setAge(5);             // événement de changement ici.

8. setAge(6);             // événement de changement ici.

9. setAge(7);             // événement de changement ici.

10. int newAge = getAge(); // retourne 7.

11. setAge(8);             // événement de changement ici.

JDK8

1. ageProperty().addListener((ObservableValue<? extends Number> observable, Number oldValue, Number newValue) -> {

2. [...]

3. });

4. setAge(5);             // événement de changement ici.

5. setAge(6);             // événement de changement ici.

6. setAge(7);             // événement de changement ici.

7. int newAge = getAge(); // retourne 7.

8. setAge(8);             // événement de changement ici.

Étant donné que les événements sont plus fréquents et transportent plus d'informations, ces listeners sont plus gourmands en ressource et en mémoire.

III-C-2-a - ChangeListener sur les nombres

Concernant les propriétés contenant des littéraux numériques, on serait tenté lorsqu'on veut enregistrer des écouteurs de faire la chose suivante :

JDK7

1. ageProperty().addListener(new ChangeListener<Integer>(){

2. @Override

3. public void changed(ObservableValue<? extends Integer> observable, Integer oldValue, Integer newValue) {

4. [...]

5. }

6. };

JDK8

1. ageProperty().addListener((ObservableValue<? extends Integer> observable, Integer oldValue, Integer newValue) -> {

2. [...]

3. };

Or cela ne fonctionnera pas, car IntegerProperty et SimpleIntegerProperty héritent de ObservableValue<Number> au lieu de ObservableValue<Integer>; il faudra donc faire à la place :

JDK7

1. ageProperty().addListener(new ChangeListener<Number>(){

2. @Override

3. public void changed(ObservableValue<? extends Number > observable, Number oldValue, Number newValue) {

4. [...]

5. }

6. });

JDK8

1. ageProperty().addListener((ObservableValue<? extends Number > observable, Number oldValue, Number newValue) -> {

2. [...]

3. });

C'est également le cas de toutes les classes de propriété qui permettent de stocker des nombres.

III-D - Threading

Tels quels, il semble que les propriétés et événements JavaFX pourront fonctionner depuis n'importe quel thread.

Attention, lorsqu'elles font partie de nœuds graphiques du SceneGraph, les propriétés sont généralement prévues pour être lancées et manipulées depuis le JavaFX Application Thread. Si des nœuds sont attachés à une scène, manipuler des propriétés dans un thread autre que le JavaFX Application Thread provoquera une exception. Ce thread est habituellement démarré au lancement d'une Application JavaFX ou lors de l'utilisation d'un JFXPanel (pour afficher du JavaFX dans du Swing) ou d'un JFXCanvas (pour afficher du JavaFX dans du SWT).

IV - Mise en œuvre

IV-A - Booléens, littéraux et chaines de caractères

- javafx.beans.property.BooleanProperty - permet de stocker des valeurs booléennes.

- javafx.beans.property.IntegerProperty - permet de stocker des valeurs entières.

- javafx.beans.property.LongProperty - permet de stocker des valeurs entières longues.

- javafx.beans.property.FloatProperty - permet de stocker des valeurs flottantes.

- javafx.beans.property.DoubleProperty - permet de stocker des valeurs flottantes en précision double.

- javafx.beans.property.StringProperty - permet de stocker des chaines de caractères.

Il n'existe pas de stockage dédié pour les littéraux de type byte, char et short. Il faudra donc utiliser des IntegerProperty ou une ObjectProperty (voir plus bas) pour stocker de telles valeurs.

Chacun de ces types dispose de classes parentes qui ne permettent que la lecture seule (ex. : ReadOnlyIntegerProperty) et de classes concrètes filles prêtes à l'emploi permettant la lecture-écriture (ex. : SimpleIntegerProperty).

Comme montré précédemment, une implémentation de la propriété age peut se faire comme suit :

1. // Propriété age.

2. private final IntegerProperty age = new SimpleIntegerProperty();

4. // Getter.

5. public final int getAge() {

6. return age.get();

7. }

9. // Setter.

10. public final void setAge(int value) {

11. age.set(value);

12. }

14. // Accès à la propriété.

15. public final IntegerProperty ageProperty() {

16. return age;

17. }

IV-B - Objets

- javafx.beans.property.ObjectProperty<T> - permet de stocker tout autre type d'objets. Ici T est bien entendu le type de la valeur de la propriété.

Cette classe est dédiée au stockage des objets au sens large. Une implémentation de la propriété favoriteCar peut se faire comme suit :

1. // Propriété favoriteCar.

2. private final ObjectProperty<Car> favoriteCar = new Simple ObjectProperty<>();

4. // Getter.

5. public final Car getFavoriteCar() {

6. return favoriteCar.get();

7. }

9. // Setter.

10. public final void setFavoriteCar(Car value) {

11. favoriteCar.set(value);

12. }

14. // Accès à la propriété.

15. public final ObjectProperty<Car> favoriteCarProperty() {

16. return favoriteCar;

17. }

IV-B-1 - Listes observables

- javafx.beans.property.ListProperty<V> - permet de stocker des ObservableList<V>. Ici V est le type des objets contenus dans la liste observable.

Les listes observables (ObservableList) sont une part importante de l'API JavaFX. Elles sont énormément utilisées dans les contrôles tels que ComboBox, ListView, TableView ou les différents types de graphes et elles sont au cœur même des nœuds parents (des nœuds qui contiennent d'autres nœuds et servent de base aux layouts et aux groupes).

Imaginons que désormais nous avons non plus une, mais plusieurs voitures préférées. Nous serions tentés d'écrire quelque chose comme cela :

1. // Propriété favoriteCars.

2. private final ObjectProperty<ObservableList<Car>> favoriteCars = new SimpleObjecProperty<>();

4. // Getter.

5. public final ObservableList<Car> getFavoriteCars() {

6. return favoriteCars.get();

7. }

9. // Setter.

10. public final void setFavoriteCars(ObservableList<Car> value) {

11. favoriteCars.set(value);

12. }

14. // Accès à la propriété.

15. public final ObjecProperty<ObservableList<Car>> favoriteCarsProperty() {

16. return favoriteCars;

17. }

Malheureusement, l'implémentation d'ObjectProperty pose quelques problèmes avec l'utilisation des listes observables. Tout d'abord, quand on manipule des listes observables, on est moins intéressé par les InvalidationListener et ChangeListener qui sont lancés lorsque la propriété change de valeur (c'est-à-dire lorsque la référence sur la liste dans la propriété change : on a remplacé la liste A par une liste B dans la propriété) que par les changements opérés sur le contenu même de la liste. C'est donc un ListChangeListener qui nous intéresse : on veut savoir quand un ou plusieurs éléments de liste sont retirés ou ajoutés (un remplacement de la liste A par la liste B pouvant être considéré comme un remplacement complet, dans la propriété, des éléments de la liste A par ceux de la liste B).

Sans rentrer dans les détails d'implémentation, maintenir un ChangeListener<ObservableList<T>> sur une ObjectProperty<ObservableList<T>> dans le seul but de désinstaller (sur l'ancienne liste) et de réinstaller (sur la nouvelle liste) un ListChangeListener<T> s'avère vite fastidieux à mettre en place et ne fonctionne pas bien finalement: il y a des cas dans lesquels les événements de changement de valeur de la propriété ne sont pas lancés correctement et donc notre écouteur de liste peut ne pas être correctement installé sur la nouvelle liste de stockage.

Il existe donc un type de propriété spécialement destiné à stocker les ObservableList, il s'agit de ListProperty. La définition de notre propriété peut alors s'écrire :

1. // Propriété favoriteCar.

2. private final ListProperty<Car> favoriteCars = new SimpleListProperty<>();

4. // Getter.

5. public final ObservableList<Car> getFavoriteCars() {

6. return favoriteCars.get();

7. }

9. // Setter.

10. public final void setFavoriteCars(ObservableList<Car> value) {

11. favoriteCars.set(value);

12. }

14. // Accès à la propriété.

15. public final ListProperty<Car> favoriteCarsProperty() {

16. return favoriteCars;

17. }

Bon, après il faut quand même faire attention qu'ici la propriété est initialisée à une valeur égale à null. Et donc un l'appel suivant provoquera une NullPointerException :

1. myObject.getFavoriteCars().add(new, Car());

Il faudra donc songer à utiliser le constructeur de SimpleListProperty qui permet de passer en argument une valeur par défaut pour la propriété, par exemple une ObservableList<Car> vide créée grâce à la classe utilitaire FXCollections.

Par contre, tout ListChangeListener placé sur la propriété sera correctement transmis si l'instance de la liste change; ainsi :

JDK7

1. myObject.favoriteCarsProperty().addListener(new ListChangeListener<Car>() {

2. @Override

3. public void onChanged(ListChangeListener.Change<? extends Car> change) {

4. while (change.next()) {

5. for (Car removed : change.getRemoved()) {

6. System.out.printf("%s removed.", removed).println();

7. }

8. for (Car added : change.getAddedSubList()) {

9. System.out.printf("%s added.", added).println();

10. }

11. }

12. }

13. });

14. System.out.println(myObject.getFavoriteCars());       // Liste A.

15. myObject.setFavoriteCars(FXCollections.<Car>observableArrayList());

16. myObject.getFavoriteCars().addAll(new, Car(), new, Car(), new, Car());

17. System.out.println(myObject.getFavoriteCars());       // Liste B.

18. myObject.setFavoriteCars(FXCollections.<Car>observableArrayList());

19. System.out.println(myObject.getFavoriteCars());       // Liste C.

JDK8

1. myObject.favoriteCarsProperty().addListener((ListChangeListener.Change<? extends Car> change) -> {

2. while (change.next()) {

3. change.getRemoved().forEach((Car removed) -> {

4. System.out.printf("%s removed.", removed).println();

5. }

6. change.getAddedSubList().forEach((Car added) -> {

7. System.out.printf("%s added.", added).println();

8. }

9. }

10. });

11. System.out.println(myObject.getFavoriteCars());       // Liste A.

12. myObject.setFavoriteCars(FXCollections.<Car>observableArrayList());

13. myObject.getFavoriteCars().addAll(new, Car(), new, Car(), new, Car());

14. System.out.println(myObject.getFavoriteCars());       // Liste B.

15. myObject.setFavoriteCars(FXCollections.<Car>observableArrayList());

16. System.out.println(myObject.getFavoriteCars());       // Liste C.

Produira une sortie similaire à :

1. null                                                                     // Liste A.

2. test.Main$Car@6046f6e4 added.

3. test.Main$Car@52fb241d added.

4. test.Main$Car@6600167a added.

5. [test.Main$Car@6046f6e4, test.Main$Car@52fb241d, test.Main$Car@6600167a] // Liste B.

6. test.Main$Car@6046f6e4 removed.

7. test.Main$Car@52fb241d removed.

8. test.Main$Car@6600167a removed.

9. []                                                                       // Liste C.

On voit donc bien que l'écouteur placé sur la propriété alors que la liste était à une valeur null (liste A) est réutilisé sur la liste B et C et que le contenu de la liste est supprimé de la propriété lorsqu'on remplace la liste B (pleine) par la liste C (vide).

IV-B-2 - Tables observables

- javafx.beans.property.MapProperty<K, V> - permet de stocker des ObservableMap<K, V>. Ici, K est le type des clés et V est le type des valeurs contenues dans la table observable.

Même si elles sont moins répandues dans l'API, de la même manière que pour les listes observables, les tables observables, ObservableMap, nécessitent l'utilisation d'une classe de stockage appropriée: MapProperty qui permet la gestion automatique des MapChangelistener. Ainsi, une propriété qui contient les voitures par plaque d'immatriculation serait définie comme :

1. private final MapProperty<String, Car> carMap = new SimpleMapProperty<>();

IV-B-3 - Ensembles observables

- javafx.beans.property.SetProperty<V> - permet de stocker des ObservableSet<V>. Ici V est le type des objets contenus dans l'ensemble observable.

À l'identique, les ensembles observables, ObservableSet peuvent être stockés dans des SetProperty avec une gestion automatique des SetChangeListener.

1. private final SetProperty<String> namePool = new SimpleSetProperty<>();

IV-C - Et les Java Beans ?

L'API fournit tout un tas de classes prévues pour transformer les propriétés des Java Beans en propriétés JavaFX :

- javafx.beans.property.adapter.JavaBeanBooleanProperty - permet d'empaqueter une propriété contenant des valeurs booléennes ;

- javafx.beans.property.adapter.JavaBeanIntegerProperty - permet d'empaqueter une propriété contenant des valeurs entières ;

- javafx.beans.property.adapter.JavaBeanLongProperty - permet d'empaqueter une propriété contenant des valeurs longues ;

- javafx.beans.property.adapter.JavaBeanFloatProperty - permet d'empaqueter une propriété contenant des valeurs flottantes ;

- javafx.beans.property.adapter.JavaBeanDoubleProperty - permet d'empaqueter une propriété contenant des valeurs flottantes en double précision ;

- javafx.beans.property.adapter.JavaBeanStringProperty - permet d'empaqueter une propriété contenant des valeurs textuelles ;

- javafx.beans.property.adapter.JavaBeanObjectProperty<T> - permet d'empaqueter une propriété contenant des valeurs de type objet.

Il n'est pas possible d'instancier directement une instance de ces types, il faut passer par des builders appropriés pour chaque type. Attention des exceptions peuvent être levées lors de la construction entre autres si les getters et les setters ne sont pas trouvés sur le bean (si les conventions Java Bean n'ont pas été respectées par exemple). Cependant le builder est assez flexible pour accepter des références sur des méthodes en paramètre si besoin est.

Supposons que nous ayons un bean très simple dans le genre :

1. public class Person {

3. private int age = 30;

5. public int getAge() {

6. return age;

7. }

9. public void setAge(int age) {

10. this.age = age;

11. }

12. }

Nous allons empaqueter (wrapper) sa propriété age comme suit :

1. Person person = new Person();

2. JavaBeanIntegerProperty personAge = JavaBeanIntegerPropertyBuilder.create()

3. .bean(person).name("age")

4. .build();

Profitons-en pour mettre un InvalidationListener et un ChangeListener sur la propriété et faisons quelques tests :

JDK7

1. personAge.addListener(new InvalidationListener() {

3. @Override

4. public void invalidated(Observable o) {

5. System.out.println("age invalid.");

6. }

7. });

8. personAge.addListener(new ChangeListener<Number>(){

10. @Override

11. public void changed(ObservableValue<? extends Number> observable, Number oldValue, Number newValue) {

12. System.out.printf("age %d -> %d", oldValue, newValue).println();

13. }

14. });

15. System.out.println(personAge.get());

16. // Changement direct sur le bean.

17. person.setAge(31);

18. System.out.println(personAge.get());

19. // Changement direct sur la propriete.

20. personAge.set(32);

21. System.out.println(personAge.get());

22. System.out.println(person.getAge());

JDK8

1. personAge.addListener((Observable o) -> {

2. System.out.println("age invalid.");

3. });

4. personAge.addListener((ObservableValue<? extends Number> observable, Number oldValue, Number newValue) -> {

5. System.out.printf("age %d -> %d", oldValue, newValue).println();

6. });

7. System.out.println(personAge.get());

8. // Changement direct sur le bean.

9. person.setAge(31);

10. System.out.println(personAge.get());

11. // Changement direct sur la propriete.

12. personAge.set(32);

13. System.out.println(personAge.get());

14. System.out.println(person.getAge());

Cela nous donne :

1. 30

2. 31

3. age invalid.

4. age 30 -> 32

5. 32

6. 32

Comme nous pouvons le voir, il n'y a pas de miracles : les changements opérés directement sur le bean ne provoquent pas la levée d'événements par la propriété JavaFX. Rien dans la classe du bean ne permet en effet de suivre les changements de valeur de la propriété age. Par contre, les changements opérés sur la propriété JavaFX provoquent la levée d'événements d'invalidation et de modification ainsi que la répercussion du changement de valeur vers le bean.

Reprenons notre bean, et écrivons-le correctement cette fois; c'est-à-dire avec un support pour accepter des écouteurs de type PropertyChangeListener, ce qui est la manière Java Bean de notifier des modifications de propriétés :

1. public class Person {

3. private int age = 30;

5. public int getAge() {

6. return age;

7. }

9. public void setAge(int age) {

10. int oldAge = this.age;

11. this.age = age;

12. listenerList.firePropertyChange("age", oldAge, age);

13. }

14. private PropertyChangeSupport listenerList = new PropertyChangeSupport(this);

16. public void addPropertyChangeListener(PropertyChangeListener listener) {

17. listenerList.addPropertyChangeListener(listener);

18. }

20. public void removePropertyChangeListener(PropertyChangeListener listener) {

21. listenerList.removePropertyChangeListener(listener);

22. }

24. public void addPropertyChangeListener(String propertyName, PropertyChangeListener listener) {

25. listenerList.addPropertyChangeListener(propertyName, listener);

26. }

28. public void removePropertyChangeListener(String propertyName, PropertyChangeListener listener) {

29. listenerList.removePropertyChangeListener(propertyName, listener);

30. }

31. }

Et lors de son exécution, maintenant notre test nous retourne :

1. 30

2. age invalid.

3. age 30 -> 31

4. 31

5. age invalid.

6. age 31 -> 32

7. age invalid.

8. 32

9. 32

Désormais, les événements de changement de valeur de la propriété du bean sont correctement répercutés vers la propriété JavaFX et provoquent l'appel des écouteurs qui sont placés dessus. L'empaquetage des propriétés d'un bean Java fonctionne donc parfaitement, pour peu que le programmeur ait fait l'effort de rendre ses propriétés observables dans le bean lui-même en programmant toute la tuyauterie nécessaire !

V - Utilisation avancée

V-A - Propriétés en lecture seule

Pour créer une propriété en lecture seule, le moyen le plus simple est de commencer par supprimer le setter ou par le rendre inaccessible depuis l'extérieur de la classe. Vous pouvez cependant en conserver un private ou protected selon les besoins. Il faut ensuite transformer le type de retour de la méthode d'accès à la propriété pour ce que type retourne ne permette pas les modifications.

V-A-1 - Cacher le type réel

On serait tenté d'écrire tout simplement le code suivantqui ne causera aucun souci à la compilation et fonctionnera parfaitement :

1. // Propriété errorCount.

2. private final IntegerProperty errorCount = new SimpleIntegerProperty();

4. // Getter.

5. public final int getErrorCount() {

6. return errorCount.get();

7. }

9. // Accès à la propriété.

10. public final ReadOnlyIntegerProperty errorCountProperty() {

11. return errorCount;

12. }

Cependant, ce n'est pas du tout recommandé puisque n'importe qui peut alors caster la propriété retournée dans un type qui accepte l'écriture et ainsi casser la protection.

1. (IntegerProperty)(errorReport.errorCountProperty()).set(0);

V-A-2 - Utiliser des wrappers

Dans l'API, tous les types Simple présentés précédemment exposent des classes filles permettant d'empaqueter des valeursfacilement et de créer ensuite des propriétés en lecture seule :

- javafx.beans.property.ReadOnlyBooleanWrapper - pour les valeurs booléennes ;

- javafx.beans.property.ReadOnlyIntegerWrapper - pour les valeurs entières ;

- javafx.beans.property.ReadOnlyLongWrapper - pour les valeurs longues ;

- javafx.beans.property.ReadOnlyFloatWrapper - pour les valeurs flottantes ;

- javafx.beans.property.ReadOnlyDoubleWrapper - pour les valeurs flottantes en double précision ;

- javafx.beans.property.ReadOnlyObjectWrapper<T> - pour les objets de manière générale ;

- javafx.beans.property.ReadOnlyListWrapper<V> - pour les listes observables ;

- javafx.beans.property.ReadOnlyMapWrapper<K, V> - pour les tables observables ;

- javafx.beans.property.ReadOnlySetWrapper<V> - pour les ensembles observables.

Il est donc plus recommandé d'utiliser un wrapperpour rendre la propriété non modifiable :

1. // Propriété errorCount.

2. private final ReadOnlyIntegerWrapper errorCount = new ReadOnlyIntegerWrapper();

4. // Getter.

5. public final int getErrorCount() {

6. return errorCount.get();

7. }

9. // Accès à la propriété.

10. public final ReadOnlyIntegerProperty errorCountProperty() {

11. return errorCount.getReadOnlyProperty();

12. }

L'appel à la méthode getReadOnlyProperty() de la propriété produit un nouvel objet sur lequel on ne peut pas appeler les méthodes set() ou setValue(). Cette méthode a cependant le défaut de créer au moins deux propriétés qui sont synchronisées entre elles: la propriété interne qui est modifiable et une ou plusieurs propriétés publiques qui ne sont pas modifiables; elle est donc plus gourmande en mémoire.

V-A-3 - Étendre le type de base

Une autre méthode consiste à étendre le type de base de la propriété, ici ReadOnlyIntegerPropertyBase.

1. private class MyReadOnlyIntegerProperty extends ReadOnlyIntegerPropertyBase {

3. private int value;

4. private String name;

6. public MyReadOnlyIntegerProperty(String name) {

7. this.name = name;

8. }

10. @Override

11. public final int get() {

12. return value;

13. }

15. private void set(int newValue) {

16. value = newValue;

17. fireValueChangedEvent();

18. }

20. @Override

21. public Object getBean() {

22. return <Classe parente>.this;

23. }

25. @Override

26. public String getName() {

27. return name;

28. }

29. }

31. // Propriété errorCount.

32. private final MyReadOnlyIntegerProperty errorCount = new MyReadOnlyIntegerProperty("errorCount");

34. // Getter.

35. public final int getErrorCount() {

36. return errorCount.get();

37. }

39. // Accès à la propriété.

40. public final ReadOnlyIntegerProperty errorCountProperty() {

41. return errorCount;

42. }

Cette manière de faire permet de produire un résultat totalement sûr: la propriété n'offre aucun accès public à la méthode set(). Elle a par contre le gros désavantage d'obliger à redéfinir manuellement tous les types de toutes les propriétés utilisées dans votre code, ce qui alourdit considérablement la tâche du programmeur.

V-B - Restriction des valeurs

Il peut arriver qu'on soit obligé de mettre des restrictions sur les valeurs d'entrée d'une propriété. Dans ce cas, il est plus aisé de faire ces tests et validations de valeur saisie dans le setter de la propriété, pour, par exemple, faire des tests de sécurité, corriger la valeur saisie par l'utilisateur ou au besoin lever une exception. Cependant, dans ce cas, il est important de faire en sorte que l'accesseur de la propriété retourne une propriété en lecture seule. Si ce n'était pas le cas, il serait possible de contourner la validation effectuée dans le setter par un appel direct aux méthodes set() ou setValue() de la propriété.

On peut de nouveau utiliser un wrapper pour mettre en œuvre cette solution :

1. // Propriété chapterCount.

2. private final ReadOnlyIntegerWrapper chapterCount = new ReadOnlyIntegerWrapper();

4. // Getter.

5. public final int getChapterCount() {

6. return chapterCount.get();

7. }

9. // Setter.

10. public final void setChapterCount(int value) {

11. // Correction de la valeur saisie.

12. chapterCount.set(value < 0 ? 0 : value);

13. }

15. // Accès à la propriété... en lecture seule.

16. public final ReadOnlyIntegerProperty chapterCountProperty() {

17. return chapterCount.getReadOnlyProperty();

18. }

V-C - Optimisation

Un défaut important de l'utilisation des propriétés est qu'elles consomment plus de mémoire que de simples valeurs décrites dans l'objet. Si dans la majorité des cas, ce n'est pas un souci, cela peut s'avérer gênant lors de l'utilisation d'objets qui contiennent plusieurs dizaines de propriétés, comme, par exemple, les nœuds de l'API graphique SceneGraph.

V-C-1 - Initialisation différée

Pour pallier ce problème, en interne, l'API JavaFX utilise des initialisations différées : les références des propriétés sont initialement à null et les getters retournent des valeurs par défaut. Seuls les accès au setter et à l'accesseur initialisent la propriété à sa vraie valeur.

1. // Propriété background.

2. private ObjectProperty<Color> background = null;

4. // Getter.

5. public final Color getBackground() {

6. return (background == null) ? Color.BLACK : background.get();

7. }

9. // Setter.

10. public final void setBackground(Color value) {

11. backgroundProperty().set(value);

12. }

14. // Accès à la propriété.

15. public final ObjectProperty<Color> backgroundProperty() {

16. if (background == null) {

17. background = new SimpleObjectProperty<>(this, "background", Color.BLACK);

18. }

19. return background;

20. }

V-C-2 - Externalisation des propriétés

Les propriétés les moins utilisées peuvent être regroupées et externalisées dans une classe de support à l'extérieur de l'objet. Ce dernier n'a plus alors qu'à initialiser une référence vers cette classe de support quand un accès est fait à une de ces propriétés. Cela permet de réduire dans notre classe principale la quantité de code à écrire pour ces propriétés et de n'avoir également à maintenir qu'une seule référence : celle vers l'objet de support.

L'API SceneGraph utilise également cette méthode d'optimisation pour les propriétés les moins utilisées des nœuds ou encore la plupart des propriétés liées au positionnement dans la 3e dimension puisque les nœuds sont principalement utilisés dans des interfaces graphiques traditionnelles en 2D.

V-C-3 - Gestion des liaisons

Toute liaison sur une propriété, que ce soit le fait d'y attacher un écouteur ou d'effectuer une liaison dessus grâce au binding peut empêcher le garbage collector de réclamer l'espace mémoire occupé par cet objet. De ce fait, il est recommandé de désinstaller les InvalidationListener et ChangeListener qui ont été enregistrés sur la propriété et de casser les liaisons en appelant les méthodes unbind() ou unbindBidirectionnal() suivant le type de binding utilisé.

V-C-3-a - Classes anonymes

Nous conservons une référence sur l'instance de notre classe anonyme pour permettre de la désinstaller quand la liaison n'est plus nécessaire :

JDK7

1. private final IntegerProperty myErrorCount = new SimpleIntegerProperty();

3. // Classe anonyme implémentant le listener.

4. private ChangeListener<Number> errorCountChangeListener = new ChangeListener<Number>() {

5. @Override

6. public void change(ObservableValue<? Extends Number> observableValue, Number oldValue, Number newValue) {

7. [...]

8. }

9. };

11. private final IntegerProperty myChapterCount = new SimpleIntegerProperty();

13. [...]

15. // Installation du listener.

16. anObject.errorCountProperty().addListener(errorCountChangeListener);

17. // Binding.

18. myChapterCount.bind(anObject.chapterCountProperty());

20. [...]

22. //Lorsqu'on veut libérer la référence :

23. // Désinstallation du listener.

24. anObject.errorCountProperty().removeListener(errorCountChangeListener);

25. errorCountChangeListener = null;

26. // Suppression du binding.

27. myChapterCount.unbind();

V-C-3-b - Lambda

Le JDK8 permet de faire la même chose avec des expressions lambda :

JDK8 avec lambda

1. private final IntegerProperty myErrorCount = new SimpleIntegerProperty();

3. // Lambda implémentant le listener.

4. private ChangeListener<Number> errorCountChangeListener = (ObservableValue<? Extends Number> observableValue, Number oldValue, Number newValue) -> {

5. [...]

6. };

8. private final IntegerProperty myChapterCount = new SimpleIntegerProperty();

10. [...]

12. // Installation du listener.

13. anObject.errorCountProperty().addListener(errorCountChangeListener);

14. // Binding.

15. myChapterCount.bind(anObject.chapterCountProperty());

17. [...]

19. //Lorsqu'on veut libérer la référence :

20. // Désinstallation du listener.

21. anObject.errorCountProperty().removeListener(errorCountChangeListener);

22. errorCountChangeListener = null;

23. // Suppression du binding.

24. myChapterCount.unbind();

V-C-3-c - Références de méthodes

En JDK 8, on peut aussi utiliser une référence de méthode :

JDK8 avec références de méthodes

1. private final IntegerProperty myErrorCount = new SimpleIntegerProperty();

3. // Méthode implémentant le listener.

4. private void impl_errorCountChangeListener(ObservableValue<? Extends Number> observableValue, Number oldValue, Number newValue) {

5. [...]

6. }

8. private final IntegerProperty myChapterCount = new SimpleIntegerProperty();

10. [...]

12. // Installation du listener.

13. anObject.errorCountProperty().addListener(this:: impl_errorCountChangeListener);

14. // Binding.

15. myChapterCount.bind(anObject.chapterCountProperty());

17. [...]

19. // Suppression du binding.

20. myChapterCount.unbind();

Attention ! Bien qu'il soit possible d'appeler la méthode removeListener() en passant en paramètre un écouteur qui soit une référence de méthode, cela n'a aucun effet à la fin (avec le JDK 8 b121 actuellement disponible). Ainsi, si nous faisons :

JDK8 avec référence de méthode

1. //Lorsqu'on veut libérer la référence :

2. // Désinstallation du listener.

3. anObject.errorCountProperty().removeListener(this:: impl_errorCountChangeListener);

Notre écouteur continuera malgré tout à recevoir des notifications de changement de propriété !

Pour contourner le problème, il faut éviter de référencer directement la méthode dans les méthodes addListener() et removeListener(). À la place, il convient de la stocker dans un membre de la classequi sera passé en paramètre de ces méthodescomme pour une classe anonyme ou une expression lambda :

JDK8 avec référence de méthode

private final IntegerProperty myErrorCount = new SimpleIntegerProperty();

// Méthode implémentant le listener.
private void impl_errorCountChangeListener(ObservableValue<? Extends Number> observableValue, Number oldValue, Number newValue) {
[...]
}

// Référence vers la méthode  impl_errorCountChangeListener()
private ChangeListener<Number> errorCountChangeListener = this:: impl_errorCountChangeListener;

private final IntegerProperty myChapterCount = new SimpleIntegerProperty();

[...]

// Installation du listener.
anObject.errorCountProperty().addListener(errorCountChangeListener);
// Binding.
myChapterCount.bind(anObject.chapterCountProperty());

[...]

//Lorsqu'on veut libérer la référence :
// Désinstallation du listener.
anObject.errorCountProperty().removeListener(errorCountChangeListener);
errorCountChangeListener = null;
// Suppression du binding.
myChapterCount.unbind();

V-C-4 - Liaisons faibles

Il est possible de faciliter la gestion des listeners en utilisant des WeakInvalidationListener et WeakChangeListener pour éviter de devoir appeler manuellement les méthodes d'enregistrement, mais cela implique de devoir conserver une référence au listener d'origine tant qu'on en a besoin sous peine de voir la liaison faible disparaitre si le garbage collector décide de libérer cet espace mémoire.

V-C-4-a - Classe anonyme

JDK7

1. private final IntegerProperty myErrorCount = new SimpleIntegerProperty();

3. // Classe anonyme implémentant le listener.

4. private ChangeListener<Number> errorCountChangeListener = new ChangeListener<Number>() {

5. @Override

6. public void change(ObservableValue<? Extends Number> observableValue, Number oldValue, Number newValue) {

7. [...]

8. }

9. };

11. [...]

13. // Installation du listener avec une référence faible.

14. anObject.errorCountProperty().addListener(new WeakChangeListener<>(errorCountChangeListener));

16. [...]

18. // Lorsqu'on veut libérer la référence :

19. errorCountChangeListener = null;

V-C-4-b - Lambda

JDK8 avec lambda

1. private final IntegerProperty myErrorCount = new SimpleIntegerProperty();

3. // Lambda implémentant le listener.

4. private ChangeListener<Number> errorCountChangeListener = (ObservableValue<? Extends Number> observableValue, Number oldValue, Number newValue) -> {

5. [...]

6. };

8. [...]

10. // Installation du listener avec une référence faible.

11. anObject.errorCountProperty().addListener(new WeakChangeListener<>(errorCountChangeListener));

13. [...]

15. // Lorsqu'on veut libérer la référence :

16. errorCountChangeListener = null;

V-C-4-c - Référence de méthode

Il n'y a pas vraiment d'équivalent pour libérer explicitement la référence lorsqu'on utilise des références de méthode directement :

JDK8 avec références de méthode

1. private final IntegerProperty myErrorCount = new SimpleIntegerProperty();

3. // Méthode implémentant le listener.

4. private void impl_errorCountChangeListener(ObservableValue<? Extends Number> observableValue, Number oldValue, Number newValue) {

5. [...]

6. }

8. [...]

10. // Installation du listener avec une référence faible.

11. anObject.errorCountProperty().addListener(new WeakChangeListener<Number>(this::impl_errorCountChangeListener));

13. [...]

15. // Il n'y a pas d'équivalent en JDK 8+références de méthode pour libérer explicitement cette référence.

Par contre, il est toujours possible d'utiliser un membre qui contient la référence à la méthode :

JDK8 avec référence de méthode

1. private final IntegerProperty myErrorCount = new SimpleIntegerProperty();

3. // Méthode implémentant le listener.

4. private void impl_errorCountChangeListener(ObservableValue<? Extends Number> observableValue, Number oldValue, Number newValue) {

5. [...]

6. }

8. // Référence vers la méthode  impl_errorCountChangeListener()

9. private ChangeListener<Number> errorCountChangeListener =  this::impl_ errorCountChangeListener;

11. [...]

13. // Installation du listener avec une référence faible.

14. anObject.errorCountProperty().addListener(new WeakChangeListener<>(errorCountChangeListener));

16. [...]

18. // Lorsqu'on veut libérer la référence :

19. errorCountChangeListener = null;

V-D - Empaqueter une valeur d'un POJO

Pour diverses raisons, il peut être nécessaire d'empaqueter des valeurs dans un objet de type ObservableValue. Ainsi, lorsque par exemple,on utilise TableView avec des objets simples Java (POJO = Plain Old Java Object), il est nécessaire de faire une telle transformation, car TableView ne fonctionne qu'avec des instances d'ObservableValue. C'est très simple : il suffit de créer au vol des propriétés dans lesquelles on mettra les valeurs.

Supposons que nous avons une requête vers une base de données qui nous renvoie des objets sous une forme de structure toute simple :

1. public classs Dog {

2. public String name;

3. public int age;

5. public Dog(String name, int age) {

6. this.name = name;

7. this.age = age;

8. }

9. }

et que nous souhaitons afficher les résultats de cette requête dans une TableView<Dog> contenant une colonne pour le nom et une pour l'âge.

Comme c'est un objet Java simple, sans propriétés JavaFX, TableView n'a absolument aucune idée de comment trouver les valeurs à afficher dans ses lignes pour chaque colonne. Pour chacune des colonnes, il va donc falloir spécifier une CellValueFactory qui, à partir d'un objet de type Dog présent sur une ligne donnée, va nous retourner un ObservableValue du type approprié pour cette colonne :

JDK7

1. // Colonne name.

2. TableColumn<Dog, String> nameColumn = TableColumnBuilder.<Dog, String>create().text("Name").build();

3. // Permet à la colonne name de récupérer la valeur dans l'objet.

4. nameColumn.setCellValueFactory(new Callback<CellDataFeatures<Dog, String>, ObservableValue<String>>(){

6. @Override

7. public  ObservableValue<String> call(CellDataFeatures<Dog, String> feature) {

8. Dog rintintin = feature.getValue();

9. return new SimpleStringProperty(rintintin.name);

10. }

11. });

12. // Colonne age.

13. TableColumn<Dog, Integer> ageColumn = TableColumnBuilder.<Dog, Integer>create().text("Age").build();

14. // Permet à la colonne age de récupérer la valeur dans l'objet.

15. ageColumn.setCellValueFactory(new Callback<CellDataFeatures<Dog, Integer>, ObservableValue<Integer>>(){

17. @Override

18. public  ObservableValue<Integer> call(CellDataFeatures<Dog, Integer> feature) {

19. Dog rintintin = feature.getValue();

20. return new SimpleObjectProperty<>(rintintin.age);

21. }

22. });

23. // Initialisation de la table.

24. ObservableList<Dog> doggies = FXCollections.observableArrayList(new Dog("Rex", 3), new Dog("Lassie", 7));

25. TableView<Dog> tableView = new TableView<Dog>();

26. tableView.getColumns().setAll(nameColumn, ageColumn);

27. tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY);

28. tableView.setItems(doggies);

JDK8

1. // Colonne name.

2. // Les builders sont dépréciés dans le JDK8 et disparaitront dans le JDK9.

3. TableColumn<Dog, String> nameColumn = new TableColumn<>("Name");

4. // Permet à la colonne name de récupérer la valeur dans l'objet.

5. nameColumn.setCellValueFactory((CellDataFeatures<Dog, String> feature) -> {

6. Dog rintintin = feature.getValue();

7. return new SimpleStringProperty(rintintin.name);

8. });

9. // Colonne age.

10. TableColumn<Dog, Integer> ageColumn = new TableColumn<>("Age");

11. // Permet à la colonne age de récupérer la valeur dans l'objet.

12. ageColumn.setCellValueFactory((CellDataFeatures<Dog, Integer> feature) -> {

13. Dog rintintin = feature.getValue();

14. return new SimpleObjectProperty<>(rintintin.age);

15. });

16. // Initialisation de la table.

17. ObservableList<Dog> doggies = FXCollections.observableArrayList(new Dog("Rex", 3), new Dog("Lassie", 7));

18. TableView<Dog> tableView = new TableView<Dog>();

19. tableView.getColumns().setAll(nameColumn, ageColumn);

20. tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY);

21. tableView.setItems(doggies);

On peut remarquer ici que j'ai utilisé un SimpleObjectProperty<Integer> au lieu d'un SimpleIntegerProperty. C'est malheureusement nécessaire puisque, comme indiqué plus haut, SimpleIntegerProperty hérite de l'ObservableValue<Number> au lieu de l'ObservableValue<Integer>.

Et voilà c'est magique, la TableView va pouvoir afficher les bonnes informations. Cela marcherait également pour un objet plus complexe comme une valeur retirée en appelant un getter sur un JavaBean.

Figure 2 - La table affiche les valeurs en provenance de nos objets.

VI - Conclusion

Voilà, nous avons fait un rapide tour pour poser les bases de l'écriture des propriétés en JavaFX. Nous avons vu que, dans la plupart des cas, la mise en place est plus rapide puisque ne nécessitant pas de devoir manuellement écrire toute la pile événementielle destinée à propager les changements de propriété.

VII - Liens

- Property Support in Java, the « Java Way ».

- Creating read-only properties in JavaFX.

- How to deal with Memory Leaks, that are caused by Binding sur les forums OTN d'Oracle.

VIII - Remerciements

Je tiens à remercier toute l'équipe du forum Développez ainsi que Mickael Baron pour ses suggestions et sa relecture du présent article. Je tiens également à remercier Philippe Duval et Malick Seck pour leurs corrections orthographiques.