IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Tutoriel sur l'API Cell de JavaFX

Comment customiser les contrôles utilisant l'API Cell tels que ComboBox, ListView, TableView, TreeView et TreeTableView.

Cet article vous montrera les bases de l'utilisation de l'API Cell de JavaFX. Cette API constitue la base des contrôles dits « virtualisés » tels que ComboBox, ListView, TableView, TreeView et TreeTableView.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum 9 commentaires Donner une note à l´article (5) 

Article lu   fois.

L'auteur

Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

Certains contrôles sont amenés à représenter à l'écran des ensembles d'objets, sous forme de liste, de boite déroulante, de table ou encore sous la forme d'un arbre graphique.

Si on se contente des apparences par défaut, les contrôles existants sont, en l'état, tout à fait capables d'afficher de simples lignes de texte contenues dans des instances de String. Cependant, les choses se corsent lorsqu'on désire afficher des objets plus complexes dont la méthode toString() ne retourne pas forcément ce qu'on désire afficher à l'utilisateur. Ici, nous avons créé des instances d'une classe Car que nous avons construite de toute pièce et nous les affichons dans une ComboBox. Comme nous n'avons pas redéfini la méthode toString() dans cette classe, l'affichage n'est… pas très sexy dirons-nous…

Image non disponible
Figure 1 - Une ComboBox ayant un affichage très quelconque.

De plus, dans une application moderne, RIA (Rich Internet Application), ou encore mobile, on ne se contentera plus guère d'utiliser seulement du texte : ainsi, une liste de contacts dans une application de messagerie peut être amenée à afficher le portrait du dit contact ou encore changer la police ou la couleur du contact en fonction de son statut en ligne. De même, une table qui liste des produits dans un magasin peut afficher une image ou photo de ce produit, un hyperlien vers le site du fabricant ou encore une barre ou des étoiles montrant sa popularité auprès des clients.

C'est ici que l'API Cell (de l'anglais « cell » qui signifie « cellule ») entre en jeu : elle permet de rapidement customiser l'apparence d'une donnée dans un contrôle pour afficher la bonne valeur, le rendre plus attrayant ou encore le rendre interactif.

II. Rappel : Swing

Petit retour en arrière pour les aficionados de Swing. Swing utilise un concept assez proche de celui des cellules : un renderer ou encore tampon encreur. Un unique cellRenderer est créé et utilisé pour représenter chaque élément de la liste : à tour de rôle, il va endosser un élément et changer son apparence pour le représenter. Il s'agit de l'application du patron du poids-mouche. Cependant, l'implémentation dans Swing a un très gros défaut : elle n'est pas performante quand on l'utilise sur des conteneurs ayant de nombreux éléments. En effet le renderer est appelé sur l'intégralité des éléments !

Dans l'exemple suivant, nous plaçons 3000 éléments dans une JList (liste graphique), elle-même placée dans un JScrollPane (zone d'affichage restreint avec barre de défilement) :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
final DefaultListModel model = new DefaultListModel();
for (int index = 0 ; index < 3000 ; index++) {
  model.addElement(index);
}
final JList list = new JList();
list.setModel(model);
list.setCellRenderer(new DefaultListCellRenderer() {
  private int called = 0;

  @Override
  public Component getListCellRendererComponent(JList<?> list, Object value, int index, boolean isSelected, boolean cellHasFocus) {
   called ++;
   System.out.println(called);
   return super.getListCellRendererComponent(list, value, index, isSelected, cellHasFocus);
  }            
);
final JScrollPane listScroll = new JScrollPane(list);
final JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setLayout(new BorderLayout());
frame.add(listScroll, BorderLayout.CENTER);
frame.setPreferredSize(new Dimension(500, 500));
frame.pack();
frame.setVisible(true);

Cela nous donne le résultat suivant à l'écran :

Image non disponible
Figure 2 - Une bonne vieille JList d'antan.

Une fois la liste affichée, un petit tour par la console va nous dévoiler une information étonnante : la méthode getListCellRendererComponent() de notre renderer, celle qui permet de customiser le tampon pour un élément à un indice donné de la liste, a été appelée plus de 3000 fois ! Pourtant seuls les 26 premiers éléments de la liste sont visibles (on aperçoit un bout de la valeur 25).

En effet, la JList a besoin de calculer sa taille maximale de manière à permettre au JScrollPane d'afficher correctement ses barres de défilement. Le renderer est donc configuré successivement pour chacun des 3000 éléments de la liste pour déterminer cette dimension. Et ce n'est pas fini ! En effet, à chaque redimensionnement de la fenêtre, cette méthode peut être appelée plus de 1000 fois ! Cette méthode est également appelée de très nombreuses fois à chaque défilement du contenu de la liste…

Ce n'est pas très efficace ! Imaginez ce qu'il en serait avec un affichage beaucoup plus complexe dans la cellule ou avec un nombre beaucoup plus grand d'éléments qui nous seraient retournés, par exemple, par une requête sur une base de données ou un SIG.

III. JavaFX

Dans JavaFX, les composants qui sont destinés à afficher un grand nombre de valeurs ont été « virtualisés », c'est-à-dire qu'ils affichent une vue qui ne contient que les éléments qui sont visibles.

III-A. Concepts de l'API Cell

Dans le cas d'une liste telle que celle ci-dessous par exemple, chaque ligne visible est représentée par une cellule. En fait, les lignes contenant des valeurs qui sont complètement en dehors de la zone d'affichage n'existent pas dans la vue. Le calcul de la hauteur totale de la liste est effectué en extrapolant les valeurs retournées par les cellules qui existent réellement et non plus sur l'intégralité des éléments de la liste. Il en va de même pour les composants qui peuvent défiler horizontalement. Il s'agit là de l'application d'un principe souvent ignoré de la programmation orientée objet : la réutilisation/le recyclage des objets existants !

virt3.png
Figure 3 - Seules les parties visibles nous intéressent.

Si on fait défiler les données, les cellules qui deviennent invisibles seront récupérées, réutilisées et reconfigurées, comme l'était le renderer de Swing, de manière à afficher les nouveaux éléments qui apparaissent sur les lignes nouvellement visibles. Si la liste est agrandie (à l'écran) de nouvelles cellules seront créées pour afficher les lignes supplémentaires.

virt.png
Figure 4 - Création et réutilisation de cellules lors du défilement.

Ici, nous voyons bien que seuls les éléments visibles sont affichés par des cellules :

  • lorsque l'élément 6 devient visible, une nouvelle cellule orange est créée ; à ce stade, l'élément 1 est encore partiellement visible, la cellule rouge est donc toujours présente ;
  • plus tard durant le défilement, la cellule rouge contenant l'élément 1 est retirée de l'affichage lorsque cet élément n'est plus visible. Cette cellule est conservée dans un pool de cellules ;
  • la cellule rouge est ensuite réutilisée lorsque l'élément 7 devient visible à son tour ;
  • la cellule vert clair contenant l'élément 2 disparait à son tour lorsque cet élément n'est plus visible.

Bien sûr, il s'agit là du fonctionnement théorique du concept : des améliorations de performances sont encore possibles dans la gestion de la vue virtuelle. Ainsi, l'API Cell disponible dans les JDK 7 et 8 effectue des appels redondants lorsqu'un élément est modifié (même en dehors du champ de la vue) : toutes les cellules visibles sont mises à jour même si ce n'est pas nécessaire. Des correctifs de performances ont été implémentés et seront probablement intégrés lors de mises à jour ultérieures du JDK8.

III-B. Mise en œuvre

Prenons le code suivant (nous reviendrons sur ce qu'il fait de manière plus détaillée ultérieurement) :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
final ListView<Integer> list = new ListView<>();
for (int index = 0; index < 3000; index++) {
    list.getItems().add(index);
}
list.setCellFactory(new Callback<ListView<Integer>, ListCell<Integer>>() {
    private int created;

    @Override
    public ListCell<Integer> call(ListView<Integer> p) {
        created++;
        System.out.println("=================Created " + created);
        return new ListCell<Integer>() {
            private int called;

            @Override
            protected void updateItem(Integer value, boolean empty) {
                final int cellIndex = created;
                called++;
                System.out.println("Called " + cellIndex + " " + called);
                super.updateItem(value, empty);
                final String text = (value == null || empty) ? null : String.valueOf(value);
                setText(text);
            }
        };
    }
});
final StackPane root = new StackPane();
root.getChildren().add(list);
final Scene scene = new Scene(root);
primaryStage.setTitle("ListView");
primaryStage.setWidth(500);
primaryStage.setHeight(500);
primaryStage.setScene(scene);
primaryStage.show();

Ici, nous remplissons également une liste graphique avec 3000 éléments. Nous spécifions une fabrique à cellules sur la ListView. Dans cette fabrique, à chaque appel à la méthode call(), nous créons une nouvelle implémentation d'une cellule capable de transformer un Integer en String pour procéder à son affichage. Cette transformation s'effectue lorsque la méthode updateItem() est appelée. Il n'y a pas besoin de spécifier un ScrollPane, les composants JavaFX peuvent afficher des barres de scroll quand nécessaire.

Cela nous donne le résultat suivant à l'écran :

Image non disponible
Figure 5 - Une ListView de nombres.

Ici, seuls les 20 premiers éléments sont visibles (la police et la hauteur des lignes dans JavaFX sont différentes de celles de Swing). Un petit tour sur la console nous montre que la méthode call() de la fabrique à cellules placée sur notre ListView a été appelée 21 fois environ (une cellule supplémentaire est créée pour la ligne affichant le nombre 20). La méthode updateItem() des cellules créées a été, quant à elle, appelée 2-3 fois en moyenne pour chaque cellule. On reste très loin des 3000+ appels dans la version Swing, même si ici, on a créé 21 objets cellule au lieu d'un seul objet renderer.

C'est lors de l'utilisation de la liste que cette manière de faire prend tout son sens : si nous faisons défiler le contenu de la liste ou si nous redimensionnons la fenêtre horizontalement, nous nous apercevons alors que seule la méthode updateItem() de chacune des 21 cellules existantes est appelée. Aucune nouvelle cellule n'est créée.

En fait la méthode call() de la fabrique à cellule n'est appelée que si nous agrandissons notre fenêtre verticalement : en effet pour chaque nouvelle ligne qui devient visible, une nouvelle cellule doit être générée.

Si on réduit au contraire la taille de la fenêtre, on se rend alors compte que la méthode updateItem() n'est appelée que sur les cellules qui sont visibles à l'écran.

Note : si on réduit la taille de la liste jusqu'à n'afficher qu'une seule ligne, les cellules non visibles sont toujours référencées en mémoire. Elles seront à nouveau utilisées si on fait défiler les données ou si on agrandit la fenêtre.

C'est un sacré gain de performances et de mémoire qui permet d'afficher des listes contenant un très très grand nombre d'éléments avec une rapidité d'affichage maximale ou encore sur des environnements restreints tels que des plateformes mobiles.

III-C. Contrôles virtualisés

Voici la liste de tous les contrôles actuels dits « virtualisés » de JavaFX et qui utilisent l'API Cell.

  • javafx.scene.control.ListView<V> : une liste graphique.
  • javafx.scene.control.ComboBox<V> : une boite déroulante.
  • javafx.scene.control.TableView<V> : une table affichant des données sur plusieurs colonnes.
  • javafx.scene.control.TreeView<V> : un arbre graphique.
  • javafx.scene.control.TreeTableView<V> : une table dont la première colonne contient un arbre. JDK8 ou supérieur.

On peut classer ces contrôles en deux grandes familles : ceux utilisant une liste d'objets et ceux utilisant une arborescence d'objets.

Les contrôles à base de liste :

  • ListView
  • ComboBox
  • TableView

Les contrôles à base d'arbre :

  • TreeView
  • TreeTableView

III-D. ChoiceBox<V>

Le contrôle javafx.scene.control.ChoiceBox<V> ne fait pas partie des contrôles supportant l'API Cell. Ce contrôle est destiné à afficher une liste déroulante et ressemble à s'y méprendre à une ComboBox. Bien qu'acceptant n'importe quel type d'objet, la liste déroulante ne peut afficher que du texte simple sans aucune possibilité d'en changer la présentation ou d'ajouter des éléments graphiques ou riches. De plus, la boite déroulante n'est pas éditable.

La propriété converter, de type StringConverter<V>, permet de spécifier un convertisseur qui prendra un élément de type V en entrée et produira une String en sortie.

Dans la plupart des cas on préfèrera sans doute utiliser ComboBox à la place de cette classe, sauf quand on doit montrer une courte liste de valeurs simples à l'utilisateur.

III-E. DatePicker

Le contrôle javafx.scene.control.DatePicker, ajouté dans le JavaFX 8, permet d'utiliser une boite déroulante pour sélectionner une date dans un calendrier qui s'affiche dans un menu surgissant. Ce contrôle utilise également l'API Cell pour générer les cellules qui servent à l'affichage de chaque jour du calendrier.

Le programmeur peut utiliser sa propriété dayCellFactory pour fournir une fabrique à cellules permettant de customiser l'apparence de certains jours dans le calendrier, par exemple : afficher les anniversaires ou les fêtes ou jours fériés ou encore des rendez-vous.

IV. L'API Cell

La classe de base de l'API Cell est la classe javafx.scene.control.Cell<V>V est le type de l'élément présent dans le conteneur. Cette classe hérite du contrôle javafx.scene.control.Labeled qui est la classe parente, entre autres, de la classe Label et des diverses classes de boutons dans l'API SceneGraph JavaFX.

IV-A. Classes

La classe Cell<V> a deux classes filles :

  • javafx.scene.control.IndexedCell<V> - qui contient une propriété index. C'est cette classe qui est utilisée dans les contrôles « virtualisés » ;
  • javafx.scene.control.DateCell - une classe de cellules utilisée par le contrôle DatePicker. JDK 8 ou supérieur.

La classe IndexedCell<V> est ensuite elle-même dérivée en classes destinées aux divers contrôles « virtualisés » :

  • javafx.scene.controle.ListView<V> - est destinée à être utilisée dans ListView<V> et ComboBox<V> ;
  • javafx.scene.controle.TableCell<V, T> - est destinée à être utilisée dans TableView<V>. Ici T est le type de l'objet affiché dans la colonne dans laquelle se trouve la cellule ;
  • javafx.scene.controle.TableRow<V> - est destinée à être utilisée dans TableView<V>. Cette classe est rarement utilisée sauf si le programmeur veut remplacer une ligne entière de la table ;
  • javafx.scene.controle.TreeCell<V> - est destinée à être utilisée dans TreeView<V> ;
  • avafx.scene.controle.TreeTableCell<V, T> - est destinée à être utilisée dans TreeTableView<V>. Ici T est le type de l'objet affiché dans la colonne dans laquelle se trouve la cellule. JDK8 ou supérieur ;
  • javafx.scene.controle.TreeTableRow<V> - est destinée à être utilisée dans TreeTableView<V>. Cette classe est rarement utilisée sauf si le programmeur veut remplacer une ligne entière de la table. JDK8 ou supérieur.

À partir de JavaFX 2.2, ces classes disposent d'une multitude de classes filles concrètes prêtes à l'emploi, spécialement destinées à afficher des champs de saisie texte, des cases à cocher, des barres de progression, ou même des boites déroulantes, etc.

Cela nous donne un graphe de hiérarchie de classes similaire à celui-ci :

Class_Hierachy_List.png
Figure 6 - Hiérarchie des classes.

IV-B. Propriétés

Le fait d'hériter de la classe Labeled, signifie qu'une cellule partage plusieurs propriétés en commun avec le contrôle Label et les divers contrôles de boutons (Button, CheckBox, RadioButton, ToggleButton, etc.). Une cellule se manipule de manière similaire :

  • la propriété text permet d'afficher du texte ;
  • le texte dans la cellule peut être configuré au moyen de diverses propriétés liées :
    • ellipsisString - le texte à utiliser en cas d'ellipse,
    • font - la police de caractères du texte,
    • lineSpacing - permet de spécifier l'espace entre les lignes en cas de texte multiligne. JDK8 ou supérieur,
    • mnemonicParsing - indique si l'API doit rechercher le caractère _ comme indicateur de raccourci clavier,
    • textAlignment - permet de spécifier l'alignement du paragraphe en cas de texte multiligne,
    • textFill - permet de spécifier la couleur ou la texture du texte,
    • textOverrun - spécifie le type d'ellipse à utiliser quand le texte doit être coupé lors de l'affichage.
    • underline - permet de spécifier si le texte doit être souligné,
    • wrapText - indique si un texte trop long peut avoir un retour à la ligne ;
  • la propriété graphic permet de spécifier un « graphique », un nœud quelconque permettant d'avoir un affichage riche :
    • une icône via une instance du contrôle ImageView,
    • un hyperlien via une instance du contrôle HyperLink,
    • un texte riche via une instance du contrôle TextFlow. JDK8 ou supérieur,
    • une apparence riche et interactive beaucoup plus complexe qu'un simple label en spécifiant n'importe quel nœud ou contrôle ;
  • le positionnement du graphique par rapport au texte peut être spécifié via diverses propriétés :
    • contentDisplay - permet de choisir entre un affichage texte seul, graphique seul ou combinant les deux ainsi que la position relative de l'un par rapport à l'autre,
    • graphicTextGap - permet de spécifier l'espacement entre le texte et le graphique ;
  • d'autres propriétés s'appliquent sur le couple texte + graphique :
    • alignement - l'alignement du couple à l'intérieur du label,
    • labelPadding - l'espacement tout autour du couple à l'intérieur du label ;
  • les accesseurs CSS contrôlant l'aspect et le positionnement du texte et du graphique sont similaires à ceux des autres classes héritant de Labeled.

De plus, la classe Cell contient des propriétés qui lui sont propres et qui permettent l'édition lorsqu'elle est utilisée dans certains contrôles :

  • editable - indique s'il est possible d'éditer le contenu de la cellule ;
  • editing - une propriété en lecture seule qui indique si le contenu de la cellule est en train d'être édité ;
  • empty - une propriété en lecture seule qui indique si la cellule est vide et qu'il n'y a pas de données à visualiser (ex. : les lignes vides d'une table qui complètent l'affichage lorsque la table contient peu de données) ;
  • item - l'objet contenu dans la cellule. La valeur null est une valeur valide sans pour autant que la cellule soit considérée comme vide ;
  • selected - une propriété en lecture seule qui indique si la cellule est sélectionnée.

Enfin, les cellules héritant de la classe IndexedCell disposent également de la propriété :

  • index - une propriété en lecture seule qui indique la position de la cellule dans le contrôle « virtualisé ».

IV-C. null vs. empty ?

On peut penser que, si on n'a pas de valeur sur une ligne, cette dernière est vide, c'est-à-dire que la propriété empty de la cellule de cette liste est à la valeur true. Ce n'est pas ainsi que cela fonctionne : la propriété empty ne prend la valeur true que lorsque la cellule est destinée à être affichée dans une région du contrôle (liste, arbre, table, etc.) où il n'y a pas de valeur : on est en dehors du champ des valeurs possibles et, par exemple dans le cas d'une liste, on a dû ajouter des lignes vierges pour compléter l'affichage.

Par exemple, imaginons une liste graphique qui affiche des entiers et qui contient les valeurs null, 0, 1, 2, 3 et 4. La capture ci-dessous nous montre ce à quoi pourrait ressembler l'affichage d'une telle liste ; ici nous avons beaucoup plus de lignes à l'écran que de données dans la liste :

Image non disponible
Figure 7 - ListView contenant null en première position.

La valeur null est affichée par la cellule de la première ligne ; ici nous avons choisi de ne rien afficher pour cette ligne. Nous aurions tout autant pu décider d'afficher le texte « <vide> » ou encore « rien » au lieu de ne rien afficher du tout. Cette ligne n'est donc pas considérée comme vide, car il y a bien une valeur, même si cette dernière est égale à null. On peut sans souci sélectionner cette ligne dans la liste graphique.

D'un autre côté, toutes les lignes situées en dessous du chiffre 4 sont effectivement vides de valeur. Il n'existe pas de valeur dans la liste pour peupler ces lignes. Une dernière précision : il n'est pas possible de sélectionner ces cellules qui sont vides puisqu'elles ne contiennent pas de donnée.

Ainsi, nous pouvons très bien avoir les deux cas de figure suivants :

  • item = null et empty = false : nous sommes sur une ligne de donnée et cette donnée est null ;
  • item = null et empty = true : nous sommes sur une ligne complémentaire et il n'y a aucune donnée à afficher, ce qui est tout à fait normal.

Pour résumer : une valeur null ne signifie pas forcément une ligne vide ; par contre une ligne vide contient toujours la valeur null. Il faudra faire bien attention à traiter correctement ces cas de figure lorsque nous serons amenés à créer nos propres cellules !

IV-D. À propos des exemples suivants

Nous allons faire un rapide tour d'horizon des divers contrôles « virtualisés » en nous attachant à chaque fois à montrer des cas de figure particuliers. Cependant, les diverses méthodes montrées sont applicables de manière générale dans l'API Cell : par exemple les astuces montrées pour les cas tournant autour de TableView peuvent être aisément appliquées à ListView ou TreeView en utilisant les classes idoines ou du code similaire.

V. Listes

Cette première série de contrôles utilise une simple liste d'objets pour stocker ses éléments (oui, même TableView !). Ces contrôles disposent donc tous de la propriété suivante :

  • items - une ObservableList<V> contenant les objets à afficher.

V-A. ListView<V>

Le contrôle javafx.scene.control.ListView<V> permet d'afficher une liste graphique, soit orientée verticalement avec une seule colonne, soit orientée horizontalement sur une seule ligne. Les listes graphiques de JavaFX sont également éditables si le besoin s'en fait sentir :

  • Affichage vertical - il s'agit de l'affichage classique le plus souvent utilisé :
Image non disponible
Figure 8 - ListView à affichage vertical.

Dans une ListView verticale, les cellules sont agencées les unes sous les autres. Chaque cellule est étendue pour remplir tout l'espace horizontal occupé par la liste graphique. Ici les cellules vides sont affichées en gris.

Image non disponible
Figure 9 - Cellules dans un affichage vertical.
  • Affichage horizontal :
Image non disponible
Figure 10 - ListView à affichage horizontal.

Dans une ListView horizontale, les cellules sont agencées les unes à côté des autres. Chaque cellule est étendue pour remplir tout l'espace vertical occupé par la liste graphique.

Image non disponible
Figure 11 - Cellules dans un affichage horizontal.

V-A-1. Propriétés

Les propriétés importantes propres à ce contrôle sont les suivantes :

  • cellFactory - de type Callback<ListView<V>, ListCell<V>> ; une fabrique à cellules qui est utilisée pour produire une cellule destinée à afficher chaque valeur visible de la liste ;
  • editable - permet de spécifier si les lignes de la liste peuvent être éditées ;
  • editingIndex - une propriété en lecture seule qui retourne l'indice de la ligne en train d'être éditée ;
  • items - une ObservableList<V> contenant les objets à afficher ;
  • fixedCellSize - permet de forcer une hauteur commune à toutes les cellules au lieu de calculer la hauteur cellule par cellule. Cette propriété est destinée à améliorer les performances de mise en page. JDK8 ou supérieur ;
  • onEditCancel - un callback appelé lorsque l'utilisateur annule son édition ;
  • onEditCommit - un callback appelé lorsque l'utilisateur valide son édition ;
  • onEditStart - un callback appelé lorsque l'utilisateur démarre son édition ;
  • onScrollTo - un callback appelé lorsque la méthode scrollTo(indice) ou scrollTo(valeur) sont invoquées. JDK8 ou supérieur ;
  • orientation - permet de spécifier si la liste est verticale ou horizontale ;
  • placeHolder - un nœud graphique à afficher lorsque la liste n'a pas de contenu. JDK8 ou supérieur.

V-A-2. En pratique

Prenons le code suivant :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
final ListView<Integer> listView = new ListView<>();
for (int index = 0; index < 3000; index++) {
    listView.getItems().add(index);
}
final StackPane root = new StackPane();
root.getChildren().add(listView);
final Scene scene = new Scene(root);
primaryStage.setTitle("ListView");
primaryStage.setWidth(300);
primaryStage.setHeight(350);
primaryStage.setScene(scene);
primaryStage.show();

Nous venons de créer une simple liste qui affiche des nombres en utilisant l'affichage par défaut.

Image non disponible
Figure 12 - Affichage simple de nombres entiers.
V-A-2-a. Bases

Imaginons maintenant que nous désirons afficher en gras et dans une couleur différente, tous les nombres premiers de cette liste. Nous avons tout d'abord besoin d'une méthode naïve permettant de déterminer si un nombre est premier :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
public static boolean isPrime(int value) {
    boolean result = true;
    if (value < 2) {
        result = false;
    } else if (value > 2) {
        if (value % 2 == 0) {
            result = false;
        } else {
            final int max = (int) (Math.ceil(Math.sqrt(value)));
            for (int i = 3; i <= max; i++) {
                if (value % i == 0) {
                    result = false;
                    break;
                }
            }
        }
    }
    return result;
}

Grâce à cette méthode, les nombres 2, 3, 5, 7, 11, 13, 17, 19, 23, 29 … sont testés positifs comme étant des nombres premiers.

Maintenant, nous allons fournir une fabrique à cellules à notre liste graphique : pour chaque ligne de la liste qui a besoin d'une nouvelle cellule, la fabrique sera appelée et une nouvelle instance de la cellule sera créée. Pour cela nous devons fournir dans la propriété cellFactory, un objet de type Callback<ListView<Integer>, ListCell<Integer>>, c'est-à-dire un callback qui prend une instance de ListView<Integer> en paramètre d'entrée et renvoie une nouvelle instance de ListCell<Integer> en sortie. Nous pouvons déclarer cela comme suit :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
listView.setCellFactory(new Callback<ListView<Integer>, ListCell<Integer>>() {

    @Override
    public ListCell<Integer> call(ListView<Integer> p) {
      // Ici nous devons créer une nouvelle cellule capable d'afficher un entier !
      […]
    }
});

Maintenant, il nous faut un type de cellule qui soit capable d'afficher un entier à l'écran. Le plus simple est encore d'étendre ListCell<Integer> dans une nouvelle classe anonyme et de surcharger la méthode updateItem(). Tant qu'à faire, ajoutons également le fait que lorsqu'on rencontre un nombre premier, on mette la police en gras, on souligne le nombre et on change la couleur du texte. Pour cela, nous allons utiliser les CSS, ce qui donne par exemple :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
new ListCell<Integer>() {

    @Override
    protected void updateItem(Integer value, boolean empty) {
        // Cet appel permet de s'assurer de la bonne configuration de la cellule.
        super.updateItem(value, empty);
        // Et maintenant, on change le texte en fonction de l'élément courant.
        final String text = (value == null || empty) ? null : String.valueOf(value);
        setText(text);
        String style = null;
        if (!empty && value != null && isPrime(value)) {
            // On utilise les CSS pour modifier l'apparence de la cellule.
            style = "-fx-font-weight: bold; -fx-text-fill: skyblue; -fx-underline: true;";
        }
        setStyle(style);
    }
};

En premier lieu, il est important d'effectuer un appel à super.updateItem() pour avoir une configuration correcte de la cellule. Si cet appel manque, la cellule peut ne pas fonctionner correctement : si vous avez, par exemple, une boite déroulante dans laquelle le fait de sélectionner une valeur dans la liste ne semble avoir aucun effet, cela est probablement dû au fait que vous avez omis d'appeler cette méthode.

Ensuite, étant donné qu'une cellule peut être amenée à être réutilisée pour afficher d'autres valeurs, il est important de réinitialiser correctement les propriétés auxquelles nous accédons, ici les propriétés text et style.

Nous pouvons finir en intégrant les deux bouts de code ensemble :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
listView.setCellFactory(new Callback<ListView<Integer>, ListCell<Integer>>() {

    @Override
    public ListCell<Integer> call(ListView<Integer> p) {
        return new ListCell<Integer>() {

            @Override
            protected void updateItem(Integer value, boolean empty) {
                super.updateItem(value, empty);
                final String text = (value == null || empty) ? null : String.valueOf(value);
                setText(text);
                String style = null;
                if (!empty && value != null && isPrime(value)) {
                    // On utilise les CSS pour modifier l'apparence de la cellule.
                    style = "-fx-font-weight: bold; -fx-text-fill: skyblue; -fx-underline: true;";
                }
                setStyle(style);
            }
        };
    }
});

À l'exécution, nous obtenons le résultat suivant : les nombres premiers s'affichent bien en gras, soulignés et en bleu ciel !

Image non disponible
Figure 13 - Mise en surbrillance des nombres premiers.
V-A-2-b. Mise en page riche

Nous allons désormais afficher un peu plus d'informations concernant nos nombres premiers : par exemple leur notation dans d'autres bases, un hyperlien vers l'encyclopédie en ligne Wikipedia ou encore une petite description.

Commençons par créer ce à quoi notre nouvelle cellule va ressembler. Plutôt que de nous embêter avec du long code Java pour créer ce nouveau composant, on peut directement créer un nouveau FXML avec SceneBuilder ou directement en codant du XML dans votre IDE. Ce nouveau composant servira de patron pour les futures cellules :

Image non disponible
Figure 14 - Création de la cellule dans SceneBuilder.
Fichier test.PrimeListCell.fxml
Cacher/Afficher le codeSélectionnez

Nous allons maintenant créer un contrôleur pour gérer correctement ce contrôle que nous avons défini dans le fichier FXML. Lorsqu'il reçoit un nombre, le contrôleur modifie les valeurs des textes des labels. De plus, en cas de clic sur l'hyperlien, il ouvre le navigateur sur une page de Wikipédia donnant plus de détails sur ce nombre. À cet effet, nous avons besoin d'une référence sur l'application actuelle. Nous allons donc rajouter deux propriétés sur ce contrôleur : une propriété value qui est le nombre à afficher et une propriété application qui est la référence vers l'application parente.

Fichier test.PrimeListCellController.java, code JDK7
Cacher/Afficher le codeSélectionnez
Fichier test.PrimeListCellController.java, code JDK8
Cacher/Afficher le codeSélectionnez

Pour rendre les choses plus lisibles, nous allons copier le code de notre cellule dans une classe séparée et nous allons lui faire charger le FXML. Le constructeur de cette classe nécessite une référence à l'application parente en paramètre ; cette référence est par la suite fournie au contrôleur du FXML.

Lorsque la méthode updateItem() est appelée, si notre nombre actuel n'est pas premier, nous utilisons une simple conversion en texte et nous mettons le graphique de la cellule à null, comme précédemment. Par contre, dans le cas d'un nombre premier, nous passons ce nombre au contrôleur du FXML, nous mettons le texte de la cellule à null et nous affichons le nœud chargé depuis le FXML en tant que graphique de la cellule.

Fichier test.PrimeListCell.java
Cacher/Afficher le codeSélectionnez

Et enfin, nous modifions le code de l'application qui génère et affiche la liste pour instancier notre nouvelle classe dans notre fabrique à cellules.

Code JDK7
Cacher/Afficher le codeSélectionnez
Code JDK8
Cacher/Afficher le codeSélectionnez

Compilons et lançons le programme. Voici le résultat !

Image non disponible
Figure 15 - Utilisation de la cellule pour les nombres premiers.

Désormais toutes les lignes qui affichent des nombres premiers arborent un affichage riche, tandis que les nombres non premiers utilisent toujours l'affichage normal. Si vous cliquez sur l'hyperlien « En savoir plus... », le navigateur par défaut de votre système devrait s'ouvrir sur l'article de Wikipédia concernant ce nombre.

V-A-2-c. Utilisation interactive

Comme indiqué tantôt, il existe plusieurs types de cellules pour listes dans l'API qui sont déjà prêtes à l'emploi. Dans cet exemple, nous allons nous intéresser à l'utilisation de la classe CheckBoxListCell<V>

Cette cellule affiche une case à cocher sur laquelle les utilisateurs peuvent cliquer. Ici, nous n'avons pas besoin de surcharger la méthode updateItem() mais à la place, nous devons fournir une ObservableValue<Boolean> pour chaque instance de la classe V contenue dans la liste. Cette propriété sera liée bidirectionnellement avec la propriété selected de la case à cocher et donc changera de valeur en conséquence.

De plus, nous pouvons fournir un StringConverter<V> qui permet de convertir une instance de la classe V en une chaine de texte pour avoir un label humainement lisible affiché à côté de la case à cocher.

Ici nous allons créer une petite interface listant des propriétés de notre application et qui sont configurables par les utilisateurs. Dans cet exemple, V est de type String, il s'agit des clés utilisées pour stocker les valeurs dans les préférences utilisateur et également pour récupérer les labels de l'UI dans le fichier contenant les traductions.

Fichier test.string.properties
Sélectionnez
1.
2.
3.
file.overwrite.confirm=Confirmer l'écrasement des fichiers ?
file.save.auto=Activer la sauvegarde automatique ?
load.last.file.on.open=Toujours ouvrir le dernier fichier au lancement ?
Code JDK7
Cacher/Afficher le codeSélectionnez
Code JDK8
Cacher/Afficher le codeSélectionnez

Et voici le résultat ! Initialement, toutes les cases sont décochées, mais si vous en cochez une et que vous redémarrez l'application, vous constaterez que la valeur a été stockée dans les préférences utilisateur et réutilisée au lancement suivant.

Image non disponible
Figure 16 - ListView contenant des CheckBox.

Si nous n'avions pas spécifié de convertisseur, au lieu d'un label humainement lisible, les clés auraient directement été affichées dans la liste graphique.

Petite astuce : la classe CheckBoxListCell dispose de plusieurs variantes de la méthode statique forListView() qui peuvent être appelées pour générer la fabrique à cellules en saisissant moins de code. Ainsi, en utilisant ces méthodes, le code devient plus aisé à lire :

 
Sélectionnez
1.
2.
// Fabrique à cellules.
listView.setCellFactory(CheckBoxListCell.forListView(propertyAccessor, labelConverter));

V-B. ComboBox<V>

Le contrôle javafx.scene.controle.ComboBox<V> permet d'afficher une boite déroulante dont il est possible d'éditer le contenu. Ce contrôle a la spécificité d'accepter deux types de cellules au lieu d'un seul.

  • Version non éditable - en général le contrôle aura un fond gris :
Image non disponible
Figure 17 - ComboBox non éditable affichant des nombres entiers.
  • Version éditable - il est possible de saisir des valeurs sur le contrôle, car sa partie gauche se comporte comme un champ de saisie textuel :
Image non disponible
Figure 18 - ComboBox éditable affichant des nombres entiers.

En y regardant de plus près, une boite déroulante est constituée de trois parties :

  • la flèche qui indique qu'il est possible de dérouler la boite, elle-même dans un bouton. Cette partie peut être configurée via les CSS tant pour sa couleur que pour sa forme ;
  • la partie « bouton », située à gauche de la flèche en général. Cette partie peut parfois être un champ d'édition. Ici elle est représentée par une cellule verte ;
  • enfin, il y a la liste qui apparait dans un menu surgissant quand on déroule la boite. Cette liste ne contient jamais de lignes vides supplémentaires. Dans cette liste, les cellules se comportent exactement comme dans une ListView.
Image non disponible
Figure 19 - Les diverses cellules d'une ComboBox.

Note : dans JavaFX 2.x, un bogue de mise en page fait que la partie bouton s'étend sur toute la largeur de la boite déroulante, y compris sous la partie réservée à la flèche. Il faudra faire attention, car le texte ou le contenu des cellules peut se retrouver caché par la partie contenant la flèche.

Dans JavaFX 8, le bouton et la partie contenant la flèche ne se chevauchent pas.

V-B-1. Propriétés

Les propriétés importantes propres à ce contrôle sont les suivantes :

  • buttonCell - de type ListCell<V> ; une cellule unique qui est utilisée pour la partie « bouton » du contrôle. Cette cellule est également amenée à servir d'éditeur lorsque le contenant est éditable ;
  • cellFactory - de type Callback<ListView<V>, ListCell<V>> ; comme dans ListView, une fabrique à cellules qui est sert à produire une cellule utilisée dans les lignes visibles de la liste déroulante qui est affichée lorsque l'utilisateur active le contrôle ;
  • converter - un convertisseur de type StringConverter<V> qui sera utilisé en mode édition pour convertir la valeur textuelle saisie par l'utilisateur en un objet de type V ;
  • editable - permet de spécifier si la partie bouton peut être éditée ;
  • editor - une propriété en lecture seule de type TextField qui retourne l'éditeur utilisé par la boite déroulante ;
  • items - une ObservableList<V> contenant les objets à afficher ;
  • placeHolder - un nœud graphique à afficher lorsque la boite déroulante n'a pas de contenu. JDK8 ou supérieur ;
  • value - la valeur de type V actuellement sélectionnée ;
  • visibleRowCount - Le nombre maximum de lignes à afficher lorsque l'utilisateur déroule la liste.

On peut donc faire varier les présentations en utilisant buttonCell et cellFactory : la boite déroulante n'est pas obligée d'arborer les mêmes présentations d'entre sa partie liste et sa partie bouton.

V-B-2. En pratique

Prenons le fichier suivant qui nous présente des espèces de poissons. Ces informations pourraient tout aussi bien avoir été générées par une requête sur une base de données. Nous y retrouvons :

  • le nom scientifique de l'espèce ;
  • le nom anglais courant de l'espèce ;
  • le nom français courant de l'espèce ;
  • son statut de conservation sur la liste rouge de l'UICN. Cette liste représente l'état de conservation des espèces animales et végétales.
Fichier test.fishes.txt
Sélectionnez
1.
2.
3.
4.
5.
6.
Thunnus albacares|Yellowfin Tuna|Thon Jaune|NT
Thunnus obesus|Bigeye Tuna|Thon obèse|VU
Katsuwonus pelamis|Skipjack Tuna|Bonite à ventre rayé|LC
Thunnus alalunga|Albacore Tuna|Germon|NT
Kajikia audax|Striped Marlin|Marlin rayé|NT
Istiompax indica|Black Marlin||DD

Nous allons les lire et puis les stocker de manière très classique :

Fichier test.Fish.java
Sélectionnez
1.
2.
3.
4.
5.
6.
public class Fish {
    String id;
    String en;
    String fr;
    UICN3_1 conservationStatus;
}

Nous ajoutons également une énumération qui définit tous les niveaux de la version 3.1 de la liste rouge de l'UICN :

Fichier test.UICN3_1.java
Cacher/Afficher le codeSélectionnez

Et enfin nous chargeons le tout et l'incluons dans notre UI :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
final List<Fish> fishList = new LinkedList<>();
fishList.add(null);
try {
    try (final InputStream input = getClass().getResourceAsStream("fishes.txt")) {
        try (final LineNumberReader in = new LineNumberReader(new InputStreamReader(input))) {
            for (String line = in.readLine(); line != null; line = in.readLine()) {
                line = line.trim();
                if (line.isEmpty()) {
                    continue;
                }
                final String[] tokens = line.split("\\|");
                final Fish fish = new Fish();
                fish.id = tokens[0];
                fish.en = tokens[1];
                fish.fr = tokens[2];
                fish.conservationStatus = UICN3_1.parse(tokens[3]);
                fishList.add(fish);
            }
        }
    }
} catch (IOException | IllegalArgumentException | IndexOutOfBoundsException ex) {
    Logger.getLogger(getClass().getName()).log(Level.SEVERE, ex.getMessage(), ex);
}
final ComboBox<Fish> comboBox = new ComboBox<>();
comboBox.getItems().setAll(fishList);
comboBox.setPrefWidth(300);
comboBox.setMaxWidth(300);
comboBox.setVisibleRowCount(5);
comboBox.getSelectionModel().select(null);
fishList.clear();
final StackPane root = new StackPane();
root.getChildren().add(comboBox);
final Scene scene = new Scene(root);
primaryStage.setTitle("ComboBox");
primaryStage.setWidth(300);
primaryStage.setHeight(350);
primaryStage.setScene(scene);

On peut remarquer que j'ai inclus la valeur null dans la liste des valeurs possibles dans la boite déroulante.

Évidemment, en l'état l'affichage est assez limité :

Image non disponible
Figure 20 - Affichage basique dans une ComboBox.

V-B-3. Affichage riche

Nous allons désormais utiliser deux cellules différentes :

  • une première cellule qui sera utilisée par le bouton, une description courte contenant juste le nom scientifique, le nom anglais et le nom français de l'espèce. Nous allons cependant utiliser un affichage complexe, car les trois mots seront affichés avec des styles de police différents ;
  • une seconde cellule avec un affichage plus détaillé qui aura une présentation différente et arborera le niveau de conservation de l'espèce ainsi qu'une image montrant le poisson en question. Ici, nous allons utiliser un style plus complexe, proche de celui utilisé par Wikipédia (version anglaise) pour afficher le tableau résumé d'une espèce :
Image non disponible
Figure 21- Extrait de la page Wikipedia anglaise « EnSkipjack tuna » en date du 28 avril 2014.

Encore une fois, pour simplifier le code de l'interface, nous allons utiliser des fichiers FXML pour définir l'apparence de nos cellules. Tout d'abord, nous définissons une classe qui étend ListCell<Fish> et dans laquelle nous chargeons nos FXML en fonction de l'apparence à utiliser. Cette cellule peut être configurée pour utiliser deux apparences :

Fichier test.FishListCell.java
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
public final class FishListCell extends ListCell<Fish> {

    /**
     * Définit les styles possibles pour cette cellule.
     */
    public enum Style {

        BARE,
        EXPANDED;
    }

    private Style style;
    private Node renderer;
    private FishListCellControllerBase rendererController;

    public FishListCell(final Style style) throws IllegalArgumentException {
        if (style == null) {
            throw new IllegalArgumentException("style est null.");
        }
        this.style = style;
        // Chargement du FXML.
        try {
            final String fxmlName = (style == Style.BARE) ? "FishListCell_Bare.fxml" : "FishListCell_Expanded.fxml";
            final URL fxmlURL = getClass().getResource(fxmlName);
            final FXMLLoader fxmlLoader = new FXMLLoader(fxmlURL);
            renderer = (Node) fxmlLoader.load();
            rendererController = (FishListCellControllerBase) fxmlLoader.getController();
        } catch (IOException ex) {
            Logger.getLogger(FishListCell.class.getName()).log(Level.SEVERE, ex.getMessage(), ex);
        }
    }

    @Override
    protected void updateItem(Fish value, boolean empty) {
        super.updateItem(value, empty);
        String text = null;
        Node graphic = null;
        if (!empty) {
            if (value == null) {
                text = (style != Style.BARE) ? "< Aucun >" : "Aucune sélection";
            } else {
                if (renderer != null) {
                    graphic = renderer;
                    rendererController.setFish(value);
                } else {
                    text = String.valueOf(value);
                }
            }
        }
        setText(text);
        setGraphic(graphic);
    }
}

Nous aurions pu définir deux classes bien distinctes, mais cela aurait mené à de la duplication de code inutile pour le chargement du fichier FXML ou encore la configuration de la cellule pour l'affichage. Pour cette même raison, j'ai défini une classe mère commune au contrôleur de chaque FXML :

Fichier test.FishListCellControllerBase.java
Cacher/Afficher le codeSélectionnez

Pour chacune de ces apparences, nous définissions un fichier CSS, FXML ainsi que le contrôleur :

  • BARE - l'apparence qui sera utilisée pour le bouton ;
Image non disponible
Figure 22 - Création de la cellule dans SceneBuilder.
Fichier test.FishListCell_Bare.fxml
Cacher/Afficher le codeSélectionnez

Nous avons attaché une feuille de style à notre FXML :

Fichier test.FishListCell_Bare.css
Cacher/Afficher le codeSélectionnez

Et il a bien sûr besoin d'un contrôleur :

Fichier test.FishListCell_BareController.java
Cacher/Afficher le codeSélectionnez
  • EXPANDED - l'apparence qui sera utilisée dans la liste.
Image non disponible
Figure 23 - Création de la cellule dans SceneBuilder.
Fichier test.FishListCell_Expanded.fxml
Cacher/Afficher le codeSélectionnez

Ce nœud graphique dispose également de sa propre feuille de style :

Fichier test.FishListCell_Expanded.css
Cacher/Afficher le codeSélectionnez

Et du contrôleur idoine :

Fichier test.FishListCell_ExpandedController.java
Cacher/Afficher le codeSélectionnez

Vous pouvez vous apercevoir que notre FXML en référence un autre : pour représenter le statut de conservation, nous allons utiliser un nouveau contrôle que nous avons créé et qui permet d'afficher un badge de couleur ainsi que les deux lettres, sigle du statut.

Image non disponible
Figure 24 - Création de l'indicateur de statut dans SceneBuilder.
Fichier test.ConservationStatusIndicator.fxml
Cacher/Afficher le codeSélectionnez

Ce nouveau contrôle dispose de sa propre feuille de style, ce qui permet de faire varier son apparence en fonction du statut de conservation courant.

Fichier test.ConservationStatusIndicator.css
Cacher/Afficher le codeSélectionnez

Et bien sûr, il dispose également de son propre contrôleur :

Fichier test.ConservationStatusIndicatorController.java, code JDK7
Cacher/Afficher le codeSélectionnez
Fichier test.ConservationStatusIndicatorController.java, code JDK8
Cacher/Afficher le codeSélectionnez

Désormais, il ne nous reste plus qu'à configurer notre boite déroulante pour qu'elle utilise les deux nouvelles cellules que nous venons de définir. Il suffit d'ajouter les lignes suivantes à notre code initial :

Code JDK7
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
comboBox.setButtonCell(new FishListCell(FishListCell.Style.BARE));
comboBox.setCellFactory(new Callback<ListView<Fish>, ListCell<Fish>>() {

    @Override
    public ListCell<Fish> call(ListView<Fish> p) {
        return new FishListCell(FishListCell.Style.EXPANDED);
    }            
});
Code JDK8
Sélectionnez
1.
2.
comboBox.setButtonCell(new FishListCell(FishListCell.Style.BARE));
comboBox.setCellFactory((ListView<Fish> listView) -> new FishListCell(FishListCell.Style.EXPANDED));

Initialement, aucune espèce n'est sélectionnée, notre boite déroulante affiche la phrase « aucune sélection », ce qui correspond au fait que notre sélection initiale a une valeur égale à null :

Image non disponible
Figure 25 - Cellule sans sélection.

Lorsque la boite est déroulée, c'est la cellule EXPANDED qui est utilisée. Le mot « Aucun » est utilisé pour afficher la valeur null, tandis que les autres valeurs utilisent l'affichage complexe et arborent le statut de conservation ainsi qu'une image de l'animal :

Image non disponible
Figure 26 - Cellules dans la liste déroulante.

Lorsqu'une valeur non null est sélectionnée, c'est la cellule BARE qui est utilisée dans le bouton pour un affichage plus concis : 

Image non disponible
Figure 27 - Cellule avec sélection.

V-C. TableView<V>

Ce contrôle est un peu plus complexe à appréhender que les deux précédents de par sa nature. Une table contient bien une liste d'objets de type V, cependant ce n'est pas le cas de ses colonnes !

D'ailleurs en parlant de colonnes, nous serons amenés à manipuler une seconde classe tout aussi importante : javafx.scene.control.TableColumn<V, T>. En effet, chaque colonne de la table opère sur deux types :

  • V qui est le type de l'objet contenu dans la table ;
  • T qui est le type de l'objet à afficher dans la colonne.

V-C-1. Propriétés

Les propriétés importantes propres à ce contrôle sont les suivantes :

  • columnResizePolicy - un callback qui permet de spécifier si les colonnes prennent tout l'espace horizontal visible ou se contentent de leur taille prédéfinie. La class TableView contient deux constantes prédéfinies qu'il est conseillé d'utiliser :
    • CONSTRAINED_RESIZE_POLICY - les colonnes prennent tout l'espace horizontal visible,
    • UNCONSTRAINED_RESIZE_POLICY - utilisation des tailles prédéfinies ;
  • comparator - une propriété en lecture seule qui contient un objet de type Comparator<V> lié au tri en cours sur la table. JDK8 ou supérieur ;
  • editable - permet de spécifier si les cellules de la table peuvent être éditées ;
  • editingCell - une propriété en lecture seule indiquant la position de la cellule en train d'être éditée ;
  • fixedCellSize - permet de forcer une hauteur commune à toutes les cellules au lieu de calculer la hauteur cellule par cellule. Cette propriété est destinée à améliorer les performances de mise en page. JDK8 ou supérieur ;
  • items - une ObservableList<V> contenant les objets à afficher ;
  • onScrollToColumn - un callback appelé lorsque la méthode scrollToColumn(indice) ou scrollToColumn(colonne) est invoquée. JDK8 ou supérieur ;
  • onScrollTo - un callback appelé lorsque la méthode scrollTo(indice) ou scrollTo(valeur) est invoquée. JDK8 ou supérieur ;
  • onSort - un callback appelé lorsque le contenu du contrôle est trié. JDK8 ou supérieur ;
  • placeHolder - un nœud graphique à afficher lorsque la table n'a pas de contenu. JDK8 ou supérieur ;
  • rowFactory - une fabrique qui génère une cellule destinée à représenter une ligne entière de la table. Généralement on utilisera la fabrique par défaut ;
  • selectionModel - gère la sélection dans la table. Généralement on utilisera le modèle par défaut ;
  • sortPolicy - la politique de tri à appliquer sur le contenu de la table. JDK8 ou supérieur ;
  • tableMenuButtonVisible - permet d'afficher un bouton autorisant l'utilisateur à accéder à un menu contrôlant la présence ou non de certaines colonnes.

Visiblement, ce n'est pas dans la table que se cachent les méthodes permettant d'accéder aux fabriques à cellules des colonnes. Il nous faut donc jeter un coup d'œil sur les propriétés de la classe TableColumn<V, T> :

  • cellFactory - de type Callback<TableColumn<V, T>, TableCell<V, T>> ; une fabrique à cellules qui est utilisée pour produire une cellule destinée à afficher chaque valeur T de la colonne associée à chaque valeur V de la table ;
  • cellValueFactory - très importante et à ne pas confondre avec la précédente : une fabrique qui, pour chaque valeur V de la table retourne une ObservableValue<T> pour cette colonne. Cette fabrique sert donc à peupler les valeurs de la colonne à partir de celles de la table ;
  • onEditCancel - un callback appelé lorsque l'utilisateur annule son édition ;
  • onEditCommit - un callback appelé lorsque l'utilisateur valide son édition ;
  • onEditStart - un callback appelé lorsque l'utilisateur démarre son édition ;
  • sortType - indique si la colonne est triée de manière ascendante ou descendante quand un tri est appliqué sur la table ;
  • tableView - une propriété en lecture seule qui contient une référence vers la table parente.

V-C-2. cellValueFactory

La propriété cellValueFactory est donc quelque chose de très important pour la colonne : c'est via cette fabrique que l'on peut extraire les objets de type T qui peuplent la colonne à partir des objets de type V qui sont présents dans la table.

Prenons par exemple la classe Truc suivante :

Fichier test.Truc.java
Cacher/Afficher le codeSélectionnez

Cette classe dispose de trois ensembles bien distincts de propriétés :

  • des propriétés JavaFX :
    • visible - un booléen,
    • name - une chaine de texte ;
  • des propriétés JavaBeans observables - c'est-à-dire que ces propriétés Java standard qui lèvent des évènements de type java.beans.PropertyChangeEvent lorsqu'elles sont modifiées. Il est de plus possible d'enregistrer des écouteurs de type java.beans.PropertyChangeListener sur notre objet de type Truc pour recevoir ces évènements :
    • opaque - un booléen,
    • comment - une chaine de texte ;
  • des membres en accès direct - on aurait aussi pu mettre des getters couplés à des setters simples qui ne lèvent pas de PropertyChangeEvent en cas de modification :
    • administrator - un booléen ;
    • email - une chaine de texte.

Nous allons maintenant essayer d'afficher ces différentes propriétés dans une TableView<Truc>. Compte tenu de la nature de nos différentes propriétés, nous aurons des colonnes de type TableColumn<Truc, Boolean> et TableColumn<Truc, String>.

Commençons par créer notre table et par afficher notre fenêtre :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
final TableView<Truc> tableView = new TableView<>();
tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY);
final StackPane root = new StackPane();
root.getChildren().add(tableView);
final Scene scene = new Scene(root, 500, 150);
primaryStage.setTitle("TableView");
primaryStage.setScene(scene);
primaryStage.show();

Évidemment, pour le moment, le résultat est un peu vide à l'affichage : la table ne contient aucune colonne !

Image non disponible
Figure 28 - Une TableView complètement vide.

Il nous faut aussi bien sûr ajouter les colonnes appropriées :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
// Construction de la table.
final TableColumn<Truc, Boolean> visibleColumn = new TableColumn<>("Visible");
final TableColumn<Truc, String> nameColumn = new TableColumn<>("Nom");
final TableColumn<Truc, Boolean> opaqueColumn = new TableColumn<>("Opaque");
final TableColumn<Truc, String> commentColumn = new TableColumn<>("Commentaires");
final TableColumn<Truc, Boolean> administratorColumn = new TableColumn<>("Administrateur");
final TableColumn<Truc, String> emailColumn = new TableColumn<>("Mél");
tableView.getColumns().setAll(visibleColumn, nameColumn, opaqueColumn, commentColumn, administratorColumn, emailColumn);
Image non disponible
Figure 29 - Ajout des colonnes.

De même qu'au moins une valeur !

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
final Truc t = new Truc();
t.setVisible(true);
t.setName("foo");
t.setOpaque(true);
t.setComment("Foo alors !");
t.administrator = false;
t.email = "foo@foo.foo";
tableView.getItems().add(t);
Image non disponible
Figure 30 - Ajout des valeurs.

Nous avons bien quelque chose sur la première ligne de notre table, puisque nous pouvons la sélectionner, mais pour le moment rien ne s'affiche étant donné que les colonnes sont totalement incapables de récupérer les valeurs appropriées à partir de l'objet t.

V-C-2-a. Propriétés JavaFX

Quand on utilise des propriétés JavaFX, c'est bien simple : il n'y a pas grand-chose à faire ! Nous pouvons utiliser la classe javafx.scene.control.cell.PropertyValueFactory<V, T> pour créer une fabrique de propriétés utilisant la réflexion. Et tout fonctionne directement !

 
Sélectionnez
1.
2.
3.
4.
// Propriété visible.
visibleColumn.setCellValueFactory(new PropertyValueFactory<>("visible"));
// Propriété name.
nameColumn.setCellValueFactory(new PropertyValueFactory<>("name"));
Image non disponible
Figure 31 - Ajout du support des propriétés JavaFX.

Si les propriétés visible et name sont modifiées ailleurs que dans la table, alors cette dernière se met à jour automatiquement avec les nouvelles valeurs.

V-C-2-b. Propriétés JavaBeans observables

Au premier abord, on peut penser qu'il suffit d'utiliser la classe PropertyValueFactory sur les propriétés opaque et comment et si on essaie, on verra que les valeurs correctes s'affichent. Mais en fait cela est trompeur : les valeurs initiales sont bien affichées ; cependant, en cas de modification hors de la table, cette dernière ne se met pas à jour ! Cela peut être gênant…

Nous allons devoir spécifier nos propres fabriques de valeurs pour ces deux propriétés et nous allons utiliser les builders présents dans l'API JavaFX qui permettent de créer un adaptateur entre les propriétés JavaBeans observables et les propriétés JavaFX :

Code JDK7
Cacher/Afficher le codeSélectionnez
Code JDK8
Cacher/Afficher le codeSélectionnez

En utilisant cet adaptateur, la table est prévenue de toutes modifications extérieures des propriétés opaque et comment et le contenu des cellules de la ligne change en conséquence.

Image non disponible
Figure 32 - Ajout du support des propriétés JavaBeans observables.
V-C-2-c. Autres

Nous allons créer des propriétés pour mettre en place un adaptateur destiné à convertir la valeur en provenance de l'objet vers une propriété JavaFX mais, ici il n'y a pas de secret : ces membres ou propriétés ne sont pas observables ; il est totalement impossible d'être tenu au courant d'une modification externe. De la même manière, si la table est éditable, une modification apportée sur la colonne n'est pas reportée sur l'objet.

Si on a affaire à des getters, on peut tenter l'utilisation de la classe PropertyValueFactory. Sinon, il va falloir procéder a mano :

Code JDK7
Cacher/Afficher le codeSélectionnez
Code JDK8
Cacher/Afficher le codeSélectionnez

Nous avons enfin l'affichage complet de nos colonnes :

Image non disponible
Figure 33 - Le contenu de nos deux dernières colonnes est enfin affiché.

V-C-3. En pratique

Nous avons désormais des valeurs qui s'affichent dans notre table, même si la présentation laisse un peu à désirer. Revenons maintenant à nos moutons : l'utilisation des cellules pour changer l'apparence de la table. Nous avons enfin réussi à peupler une table d'instances de la classe Truc et à afficher des valeurs, certes, mais ça serait sans doute bien si nos valeurs booléennes étaient affichées par des cases à cocher, n'est-ce pas ?

V-C-3-a. Booléens

L'API JavaFX propose la classe prête à l'emploi javafx.scene.control.cell.CheckBoxTableCell qui peut être utilisée pour représenter des valeurs booléennes sous forme de cases à cocher. De plus, ici, nous n'aurons même pas besoin d'écrire une nouvelle classe ou un nouveau callback, puisque CheckBoxTableCell propose directement une fabrique statique. L'appel à la méthode forTableColumn() permet de générer le callback qui sera chargé de créer les cellules de ces colonnes. Il nous suffit donc d'insérer dans notre code :

 
Sélectionnez
visibleColumn.setCellFactory(CheckBoxTableCell.forTableColumn(visibleColumn));
opaqueColumn.setCellFactory(CheckBoxTableCell.forTableColumn(opaqueColumn));
administratorColumn.setCellFactory(CheckBoxTableCell.forTableColumn(administratorColumn));

pour que notre affichage se dote de cases à cocher dans les colonnes contenant des valeurs booléennes :

Image non disponible
Figure 34 - Changement d'affichage pour les valeurs booléennes.
V-C-3-b. Édition

Nous allons maintenant rendre notre table éditable. Nous allons mettre des écouteurs sur les propriétés observables dans notre objet t ; cela nous permettra de vérifier que nous modifions réellement les valeurs contenues qu'il contient. Ces propriétés observables sont les propriétés visible, name, opaque et comment. Les propriétés administrator et email ne sont pas, quant à elles, directement observables en l'état donc nous ne pouvons pas enregistrer d'écouteurs dessus.

Code JDK7
Cacher/Afficher le codeSélectionnez
Code JDK8
Cacher/Afficher le codeSélectionnez

Désormais, nous serons tenus au courant de toute modification sur ces propriétés par des affichages sur la console.

Pour qu'une valeur soit éditable dans la table, il faut que la table soit marquée comme éditable bien sûr, mais aussi que la colonne le soit. Commençons donc par insérer les lignes suivantes dans notre code :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
visibleColumn.setEditable(true);
nameColumn.setEditable(true);
opaqueColumn.setEditable(true);
commentColumn.setEditable(true);
administratorColumn.setEditable(true);
emailColumn.setEditable(true);
tableView.setEditable(true);

Et… et c'est tout en ce qui concerne les propriétés visible et opaque ! Il est en effet possible, dans la table, de cocher et décocher les cases, ce qui provoque immédiatement des affichages dans la console similaires à :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
Opaque true -> false
Opaque false -> true
Opaque true -> false
Opaque false -> true
Visible true -> false
Visible false -> true
Visible true -> false
Visible false -> true

Ce qui démontre que notre objet t reçoit bien les nouvelles valeurs booléennes qui ont été éditées dans la table.

Par contre, les colonnes contenant les valeurs des propriétés name, comment et email ne semblent pas vouloir être éditées : si on essaie de cliquer ou de double-cliquer sur le contenu de la cellule, rien ne se passe. Le problème se situe en fait au niveau de la cellule par défaut qui est produite : elle ne supporte pas l'édition. Ici aussi, l'API JavaFX vient à notre rescousse, nous allons utiliser la classe prête à l'emploi javafx.scene.control.cell.TextFieldTableCell. Cette classe permet d'utiliser un champ de saisie texte lors du passage en mode édition. Comme précédemment, il suffit d'appeler la méthode statique forTableColumn() pour disposer d'un callback prêt à l'emploi qui servira de fabrique de cellules. Insérons les lignes suivantes dans notre code :

Code JDK7
Cacher/Afficher le codeSélectionnez
Code JDK8
Cacher/Afficher le codeSélectionnez

Au lancement, aucun changement n'est discernable, la table est totalement identique à ce que nous avions précédemment.

Image non disponible
Figure 35 - Affichage au démarrage.

Cependant, si on double-clique sur une des colonnes contenant du texte, désormais, la cellule va basculer en mode édition.

Image non disponible
Figure 36 - Passage en mode édition.

Les valeurs éditées dans les colonnes contenant les propriétés name et comment sont immédiatement reportées vers l'objet t une fois la validation effectuée, comme nous le montre l'affichage sur la console :

 
Sélectionnez
1.
2.
Nom foo -> Truc
Commentaire Foo alors !!!! -> Un chasseur sachant chasser...

Les propriétés administrator et email vont demander un peu plus de travail ! Bien qu'il soit possible d'éditer le contenu de la table, les modifications ne sont pas reportées vers l'objet t.

En ce qui concerne la propriété email, nous allons utiliser un callback sur la colonne. En effet, il nous suffit de placer un callback sur la propriété onEditCommit de la colonne : cette propriété est appelée lorsque l'utilisateur valide son édition. Nous pouvons donc récupérer la nouvelle valeur et la stocker dans notre objet :

Code JDK7
Cacher/Afficher le codeSélectionnez
Code JDK8
Cacher/Afficher le codeSélectionnez

Désormais, la propriété email est correctement mise à jour en cas d'édition !

 
Sélectionnez
1.
Mél foo@foo.foo ->

On serait tenté de faire quelque chose de similaire avec la propriété administrator. Cependant, si on le faisait, on se rendrait compte que le callback n'est jamais appelé. Le concepteur de CheckBoxTableCell a en effet estimé qu'il n'était pas utile que ce composant passe en mode édition lors de son activation. Après tout lors d'un clic, le changement de valeur est immédiatement reporté vers la propriété source dans la colonne.

Nous allons donc pallier ce problème en établissant un écouteur dans le code qui retourne une valeur observable à partir de notre objet t.

Code JDK7
Cacher/Afficher le codeSélectionnez
Code JDK8
Cacher/Afficher le codeSélectionnez

Désormais, en cas de modification de cette valeur dans la table, le membre correspondant dans l'objet est également correctement modifié !

V-C-3-c. Édition avancée

Pour le moment, nous avons vu comment utiliser les éditeurs fournis par l'API. Mais il est grand temps de se lancer dans la création d'éditeurs pour les cellules de notre table.

Les couleurs en JavaFX sont des objets immutables, c'est-à-dire qu'on ne peut pas les modifier après leur création. Pour cette même raison, les composants R (rouge), G (vert) et B (bleu) d'une couleur ne sont pas des propriétés observables. Cependant dans le cadre d'un éditeur, on peut être amené à vouloir modifier ces composantes. Commençons par définir une nouvelle classe qui représentera une couleur mutable. Cette nouvelle classe, MyColor, contiendra :

  • color - une référence vers une couleur JavaFX. Modifier cette propriété modifie immédiatement les valeurs des autres propriétés ;
  • red - la composante rouge. Modifier cette propriété modifie immédiatement la valeur de la propriété color sans toucher aux autres propriétés ;
  • green - la composante vert. Modifier cette propriété modifie immédiatement la valeur de la propriété color sans toucher aux autres propriétés ;
  • blue - la composante bleu. Modifier cette propriété modifie immédiatement la valeur de la propriété color sans toucher aux autres propriétés.
Fichier test.MyColor.java, code JDK7
Cacher/Afficher le codeSélectionnez
Fichier test.MyColor.java, code JDK8
Cacher/Afficher le codeSélectionnez

Et bien évidemment, il nous faut désormais une table pour afficher ces couleurs :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
final TableView<MyColor> tableView = new TableView<>();
tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY);
//
final TableColumn<MyColor, Color> colorColumn = new TableColumn<>("Couleur");
colorColumn.setCellValueFactory(new PropertyValueFactory<>("color"));
final TableColumn<MyColor, Double> redColumn = new TableColumn<>("Rouge");
redColumn.setCellValueFactory(new PropertyValueFactory<>("red"));
final TableColumn<MyColor, Double> greenColumn = new TableColumn<>("Vert");
greenColumn.setCellValueFactory(new PropertyValueFactory<>("green"));
final TableColumn<MyColor, Double> blueColumn = new TableColumn<>("Bleu");
blueColumn.setCellValueFactory(new PropertyValueFactory<>("blue"));
tableView.getColumns().setAll(colorColumn, redColumn, greenColumn, blueColumn);
//
final StackPane root = new StackPane();
root.getChildren().add(tableView);
final Scene scene = new Scene(root, 500, 250);
primaryStage.setTitle("TableView");
primaryStage.setScene(scene);
////////////////////////////////////////////////////////////////////////
tableView.getItems().setAll(new MyColor(Color.WHITE), new MyColor(Color.BLACK),
        new MyColor(Color.GOLD),
        new MyColor(Color.RED), new MyColor(Color.GREEN), new MyColor(Color.BLUE),
        new MyColor(Color.MAGENTA), new MyColor(Color.YELLOW), new MyColor(Color.CYAN)
);

Ce qui nous donne le résultat suivant :

Image non disponible
Figure 37 - Un affichage de couleurs pas très coloré…

Pour le moment, même si nous récupérons correctement les valeurs stockées, nous avons uniquement du texte qui s'affiche. Nous allons commencer par essayer d'afficher un rectangle de couleur dans la première colonne. Nous allons donc définir une nouvelle cellule capable de dessiner un rectangle coloré.

Fichier test.ColorTableCell.java, code JDK7
Cacher/Afficher le codeSélectionnez
Fichier test.ColorTableCell.java, code JDK8
Cacher/Afficher le codeSélectionnez

Ici, nous utilisons une instance de Region en tant que graphique de la cellule. Cette région sera colorée grâce aux CSS lorsque la méthode updateItem() est appelée sur la couleur contenue dans la colonne. Nous avons également doté cette classe d'une fabrique statique ce qui permettra d'alléger un peu notre code principal.

Nous pouvons désormais invoquer notre cellule en faisant :

 
Sélectionnez
1.
colorColumn.setCellFactory(ColorTableCell.forTableColumn());

Ceci fait, la première colonne de notre table affiche désormais des rectangles de couleur au lieu de chaines de texte :

Image non disponible
Figure 38 - Utilisation de cellules permettant d'afficher la couleur.

Maintenant, nous allons rendre cette colonne éditable :

 
Sélectionnez
1.
2.
tableView.setEditable(true);
colorColumn.setEditable(true);

Pour le moment, il ne se passe pas grand-chose si on double-clique sur une des cellules colorées. La cellule ne passe pas en mode édition, car sa classe mère TableCell ne supporte aucun éditeur. C'est donc à nous de jouer désormais pour ajouter cette fonctionnalité. Pour éviter de trop encombrer cet article avec du code, nous allons essayer d'utiliser ici un contrôle déjà présent dans l'API plutôt que d'en créer un nouveau.

Le contrôle javafx.scene.control.ColorPicker permet de sélectionner et d'éditer une couleur : il s'agit d'une boite déroulante qui affiche un carré coloré et le nom de la couleur. Son menu surgissant affiche une présélection de couleur et il est possible de faire apparaitre une boite de dialogue contenant des options d'édition avancées. Ce contrôle semble donc tout à fait adapté pour notre besoin et nous allons essayer de l'insérer dans notre cellule lorsque celle-ci passe en mode édition.

Image non disponible
Figure 39 - Les différents états d'un ColorPicker.

Telle quelle, la classe TableCell ne supporte aucun éditeur, mais dispose tout de même de toute l'infrastructure nécessaire pour supporter le mode édition. Plusieurs méthodes sont fournies à cet effet :

  • cancelEdit() - une méthode appelée lorsque l'utilisateur annule son édition ;
  • commitEdit() - une méthode appelée lorsque l'utilisateur valide son édition. Cette méthode prend en paramètre la nouvelle valeur après édition ;
  • starEdit() - une méthode appelée lorsque l'utilisateur démarre son édition.

Nous allons donc surcharger ces méthodes en prenant garde à chaque fois d'appeler la super méthode. Ce faisant, lorsque l'édition démarre dans notre cellule, un ColorPicker sera inséré en tant que graphique. Lorsque l'édition est annulée ou, au contraire, lorsque l'utilisateur a validé une nouvelle couleur, nous devrons réinsérer la région colorée en tant que graphique de la cellule. De plus, lorsque l'utilisateur a choisi une nouvelle couleur, nous devons propager la nouvelle valeur.

Nous allons insérer les lignes de code suivantes dans le code de notre classe ColorTableCell :

Code JDK7
Cacher/Afficher le codeSélectionnez
Code JDK8
Cacher/Afficher le codeSélectionnez

Lorsque la méthode startEdit() est appelée, nous initialisons notre éditeur et ajoutons un écouteur sur sa propriété value qui permet de savoir quand l'utilisateur effectue une sélection. Nous ajoutons également un callback pour capturer la touche clavier ESC et annuler l'édition si besoin. Enfin nous remplaçons le graphique de la cellule par notre éditeur.

Lorsque la méthode cancelEdit() est appelée, nous effectuons un petit nettoyage et nous restaurons le graphique initial de la cellule, c'est-à-dire la région colorée.

Lorsque la valeur change dans l'éditeur, nous appelons la méthode commitEdit() avec la nouvelle valeur comme paramètre. Cela permettra de propager les changements jusqu'à l'objet source. Puis nous effectuons les mêmes actions qu'en cas d'annulation pour restaurer l'affichage initial.

Image non disponible
Figure 40 - Utilisation de l'éditeur dans la table.

Désormais, si l'utilisateur double-clique sur une cellule, notre cellule passe correctement en mode édition. De plus, s'il choisit une couleur dans notre ColorPicker, le contenu de notre table est correctement mis à jour et les changements de valeurs sont également propagés aux autres colonnes. Avec un petit peu de travail côté CSS, il serait même possible de faire que l'apparence de notre éditeur soit un peu mieux intégrée avec celle de notre table, mais c'est un boulot pour un autre article…

Image non disponible
Figure 41 - En sortie d'éditeur, la nouvelle couleur est appliquée dans la table.

Il nous est désormais possible de définir également des éditeurs customisés pour les trois autres colonnes. Cependant, ici, nous allons utiliser une approche différente : nous allons utiliser le composant javafx.scene.control.Slider en tant qu'éditeur. Étant donné que nous allons éditer la valeur « au vol » en déplaçant le bouton de la réglette, nous n'entrons jamais en mode édition. Nous allons donc utiliser une approche similaire à celle utilisée par CheckBoxTableCell : nous allons effectuer une liaison bidirectionnelle directement sur la propriété contenue dans la cellule.

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
package test;

import javafx.beans.binding.Bindings;
import javafx.beans.property.DoubleProperty;
import javafx.beans.value.ObservableValue;
import javafx.scene.Node;
import javafx.scene.control.Slider;
import javafx.scene.control.TableCell;
import javafx.scene.control.TableColumn;
import javafx.util.Callback;

public final class ColorComponentTableCell<T> extends TableCell<T, Double> {

    /**
     * La dernière propriété sur laquelle l'éditeur a été lié.
     */
    private ObservableValue<Number> numberProperty;
    /**
     * L'éditeur.
     */
    private Slider slider = new Slider();

    public ColorComponentTableCell() {
        slider.setMin(0);
        slider.setMax(1);
    }

    @Override
    protected void updateItem(Double value, boolean empty) {
        super.updateItem(value, empty);
        setText(null);
        Node graphic = null;
        if (value != null && !empty) {
            graphic = slider;
            // On casse la liaison avec la propriété précédente.
            if (numberProperty instanceof DoubleProperty) {
                slider.valueProperty().unbindBidirectional((DoubleProperty) numberProperty);
            }
            // On établit une liaison avec la propriété actuelle.
            final int row = getIndex();
            final ObservableValue observableValue = getTableColumn().getCellObservableValue(row);
            if (observableValue instanceof DoubleProperty) {
                numberProperty = observableValue;
                slider.valueProperty().bindBidirectional((DoubleProperty) numberProperty);
            }
            // La réglette n'est pas activable si la cellule ou la colonne ou la table ne sont pas éditables.
            slider.disableProperty().bind(Bindings.not(
                    getTableView().editableProperty().and(getTableColumn().editableProperty()).and(editableProperty())
            ));
        }
        setGraphic(graphic);
    }

    /**
     * Fabrique statique.
     */
    public static <T> Callback<TableColumn<T, Double>, TableCell<T, Double>> forTableColumn() {
        return (TableColumn<T, Double> tableColumn) -> new ColorComponentTableCell<T>();
    }
}

Il nous suffit alors d'insérer dans le code principal :

 
Sélectionnez
1.
2.
3.
redColumn.setCellFactory(ColorComponentTableCell.forTableColumn());
greenColumn.setCellFactory(ColorComponentTableCell.forTableColumn());
blueColumn.setCellFactory(ColorComponentTableCell.forTableColumn());

Avec pour résultat, le fait que notre table se pare de réglettes sur les colonnes affichant les propriétés red, green et blue :

Image non disponible
Figure 42 - Mise en place d'instances de Slider pour changer les composantes.

Si l'utilisateur bouge le bouton d'une des réglettes, la colonne color est automatiquement mise à jour avec la nouvelle valeur de la couleur. Si une nouvelle couleur est éditée dans la première colonne, les réglettes des trois autres colonnes sont automatiquement positionnées sur les bonnes valeurs.

Image non disponible
Figure 43 - Changer les composantes modifie la couleur affichée dans la première colonne.
V-C-3-d. Lignes

Note : dans l'exemple suivant, je vais utiliser la classe java.util.Optional disponible à partir du JDK8 ainsi que l'API permettant d'activer une pseudoclasse sur un sélecteur CSS. Cette API n'est publique qu'à partir de JavaFX 8. Le code qui sera présenté dans cette section sera donc au format JDK 8.

Il arrive que dans certains cas, il soit nécessaire de définir la fabrique qui retourne une ligne de la table, par exemple :

  • on veut afficher une couleur de fond sur une ligne entière pour montrer des données importantes ou indiquer un changement d'état ;
  • on veut gérer un menu contextuel sur cette ligne.

Il est tout à fait possible de gérer ces cas de figure via la méthode habituelle en définissant chaque fabrique de cellules de chaque colonne. Cependant cette méthode n'est pas très efficace : elle oblige à effectuer beaucoup de duplications de code dans chaque cellule ainsi qu'au niveau des CSS.

Dans notre exemple nous allons créer un gestionnaire de téléchargements. Tout d'abord créons une classe Download qui va représenter un téléchargement :

Fichier test.Download.java
Cacher/Afficher le codeSélectionnez

Dans cette classe, nous avons diverses propriétés publiques en lecture seule telles que la taille maximale à télécharger ou encore la progression actuelle dans le téléchargement. Cependant, il existe des setters visibles par les autres classes du package, entre autres notre gestionnaire de téléchargements qui se chargera de rapatrier les données sur l'ordinateur local. Ces valeurs sont initialement à -1, en effet notre gestionnaire de téléchargement devra accéder au site distant pour par exemple trouver la taille du fichier à récupérer et ensuite procéder au transfert des octets.

Nous allons maintenant créer une table pour afficher les téléchargements :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
final TableView<Download> tableView = new TableView<>();
tableView.setEditable(false);
tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY);
// Colonne non.
final TableColumn<Download, String> nameColumn = new TableColumn<>("Nom");
nameColumn.setCellValueFactory((TableColumn.CellDataFeatures<Download, String> p) -> {
    final Download download = p.getValue();
    return new SimpleStringProperty(download.getName());
});
// Colonne site.
final TableColumn<Download, String> baseCodeColumn = new TableColumn<>("Site");
baseCodeColumn.setCellValueFactory((TableColumn.CellDataFeatures<Download, String> p) -> {
    final Download download = p.getValue();
    return new SimpleStringProperty(download.getCodeBase());
});
// Colonne fichier local
final TableColumn<Download, String> outputColumn = new TableColumn<>("Fichier local");
outputColumn.setCellValueFactory((TableColumn.CellDataFeatures<Download, String> p) -> {
    final Download download = p.getValue();
    return new SimpleStringProperty(download.getLocalFile().getAbsolutePath());
});
// Colonne taille.
final TableColumn<Download, Number> sizeColumn = new TableColumn<>("Taille");
sizeColumn.setCellValueFactory((TableColumn.CellDataFeatures<Download, Number> p) -> {
    final Download download = p.getValue();
    return download.sizeProperty();
});
sizeColumn.setCellFactory((TableColumn<Download, Number> p) -> {
    return new TableCell<Download, Number>() {

        @Override
        protected void updateItem(Number value, boolean empty) {
            super.updateItem(value, empty);
            String text = null;
            if (value != null && !empty) {
                text = (value.doubleValue() < 0) ? "Calcul en cours..." : value.toString();
            }
            setText(text);
        }
    };
});
// Colonne progression.
final TableColumn<Download, Number> progressColumn = new TableColumn<>("Progression");
progressColumn.setCellValueFactory((TableColumn.CellDataFeatures<Download, Number> p) -> {
    final Download download = p.getValue();
    final DoubleBinding progressProperty = new DoubleBinding() {
        {
            bind(download.progressProperty(), download.sizeProperty());
        }

        @Override
        public void dispose() {
            unbind(download.progressProperty(), download.sizeProperty());
        }

        @Override
        protected double computeValue() {
            long progress = download.getProgress();
            long size = download.getSize();
            double result = (size < 0 || progress < 0) ? -1 : progress / (double) size;
            return result;
        }
    };
    return progressProperty;
});
progressColumn.setCellFactory((TableColumn<Download, Number> p) -> {
    return new TableCell<Download, Number>() {
        private final ProgressBar progressBar = new ProgressBar();

        {
            progressBar.setMaxWidth(Double.MAX_VALUE);
        }

        @Override
        protected void updateItem(Number value, boolean empty) {
            super.updateItem(value, empty);
            String text = null;
            Node graphic = null;
            if (value != null && !empty) {
                if (value.doubleValue() >= 1) {
                    final Label label = new Label("Terminé !");
                    label.setMaxWidth(Double.MAX_VALUE);
                    HBox.setHgrow(label, Priority.ALWAYS);
                    final Button button = new Button("Ouvrir");
                    button.setStyle("-fx-padding: 3; -fx-font-size: 0.8em;");
                    button.setOnAction((ActionEvent t) -> {
                        final Download download = getTableView().getItems().get(getIndex());
                        final File file = download.getLocalFile();
                        getHostServices().showDocument(file.toURI().toString());
                    });
                    final HBox content = new HBox(label, button);
                    content.setAlignment(Pos.BASELINE_LEFT);
                    graphic = content;

                } else {
                    progressBar.setProgress(value.doubleValue());
                    graphic = progressBar;
                }
            }
            setText(text);
            setGraphic(graphic);
        }
    };
});
// Peuplement des colonnes de la table.
tableView.getColumns().setAll(nameColumn, baseCodeColumn, sizeColumn, outputColumn, progressColumn);
//
final StackPane root = new StackPane();
root.getChildren().add(tableView);
final Scene scene = new Scene(root, 850, 300);
primaryStage.setTitle("TableView");
primaryStage.setScene(scene);
primaryStage.show();

Ici, la colonne qui renseigne la taille affiche « Calcul en cours… » tant que cette dernière n'a pas été initialisée par le gestionnaire de téléchargements. Notre colonne qui affiche la progression contient une cellule qui affiche une barre de progression montrant l'avancement du téléchargement de notre fichier. Une fois le téléchargement accompli, elle affichera un label « Terminé » ainsi qu'un bouton permettant d'ouvrir le fichier local.

Nous allons maintenant peupler la table avec des téléchargements à effectuer :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
// Peuplement de la table.
final String[] values = {
    "http://cygwin.com/setup-x86.exe",
    "http://cygwin.com/setup-x86_64.exe",
    "http://cran.r-project.org/src/base/R-3/R-3.1.0.tar.gz"
};
final File downloadFolder = new File(System.getProperty("user.home"), "Downloads");
for (String value : values) {
    try {
        final URL url = new URL(value);
        final Download download = new Download(url, downloadFolder);
        tableView.getItems().add(download);
    } catch (MalformedURLException ex) {
        Logger.getLogger(Test_TableView.class.getName()).log(Level.SEVERE, ex.getMessage(), ex);
    }
}

Désormais notre table prend vie :

Image non disponible
Figure 44 - Colonne avec barre de progression.

Coder un vrai gestionnaire de téléchargements serait hors de propos pour ce didacticiel, donc je vais me contenter de coder ici un timer qui va simuler le téléchargement de la première ligne de la table.

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
// Simulation du téléchargement.
final PauseTransition simulatorTimer = new PauseTransition(Duration.seconds(5));
simulatorTimer.setOnFinished((ActionEvent t) -> {
    final Download download = tableView.getItems().get(0);
    // Initialisation de la taille et de la progréssion.
    download.setSize(300000);
    download.setProgress(0);
    final SequentialTransition downloadAnimation = new SequentialTransition();
    final PauseTransition downloadAction = new PauseTransition(Duration.millis(150));
    downloadAction.setOnFinished((final ActionEvent actionEvent) -> {
        final long progress = download.getProgress();
        final long size = download.getSize();
        final int increment = 5000;
        if (progress + increment >= size) {
            download.setProgress(size);
            downloadAnimation.stop();
        } else {
            download.setProgress(progress + increment);
        }
    });
    downloadAnimation.getChildren().setAll(downloadAction);
    downloadAnimation.setCycleCount(PauseTransition.INDEFINITE);
    downloadAnimation.play();
});
simulatorTimer.play();

Après une pause de cinq secondes lors de l'affichage de la fenêtre, nous initialisons la taille de notre premier fichier à 300 000 octets puis nous lançons une animation qui va boucler en incrémentant la progression jusqu'à atteindre la taille maximale.

Lorsque le faux téléchargement est en cours, nous obtenons l'apparence suivante :

Image non disponible
Figure 45 - Téléchargement en cours.

Puis lorsque la simulation est finie :

Image non disponible
Figure 46 - Téléchargement terminé.

Nous allons maintenant effectuer les deux modifications suivantes :

  • lorsqu'un téléchargement est fini, le fond de la ligne passe en vert et les labels qui s'y trouvent deviennent gras ;
  • nous allons implémenter un menu contextuel qui, lors d'un clic droit sur la ligne, permettra d'effectuer des actions telles que retirer un téléchargement de la liste, le mettre en pause ou encore le relancer…

Pour cela, définissons la classe suivante qui servira de cellule pour chaque ligne :

Fichier test.DownloadTableRow.java
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
package test;

import java.net.URL;
import java.util.Optional;
import javafx.animation.PauseTransition;
import javafx.beans.InvalidationListener;
import javafx.beans.Observable;
import javafx.css.PseudoClass;
import javafx.event.ActionEvent;
import javafx.scene.control.ContextMenu;
import javafx.scene.control.MenuItem;
import javafx.scene.control.SeparatorMenuItem;
import javafx.scene.control.TableRow;
import javafx.util.Duration;

public final class DownloadTableRow extends TableRow<Download> {

    /**
     * La valeur actuelle.
     * Ici, on utilise la classe Optional donc value n'est jamais null.
     */
    private Optional<Download> value = Optional.empty();
    private final ContextMenu contextMenu = new ContextMenu();

    public DownloadTableRow() {
        super();
        getStyleClass().add("download-table-row");
        // Chargement de la feuille de style.
        final URL cssURL = getClass().getResource("DownloadTableRow.css");
        getStylesheets().add(cssURL.toExternalForm());
        //
        final MenuItem restartItem = new MenuItem("Relancer");
        restartItem.setId("restartItem");
        restartItem.setOnAction((final ActionEvent actionEvent) -> value.ifPresent((final Download d) -> System.out.printf("Relancer %s", d.getName()).println()));
        final MenuItem pauseItem = new MenuItem("Mettre en pause");
        pauseItem.setId("pauseItem");
        pauseItem.setOnAction((final ActionEvent actionEvent) -> value.ifPresent((final Download d) -> System.out.printf("Mise en pause de %s", d.getName()).println()));
        final MenuItem resumeItem = new MenuItem("Reprendre");
        resumeItem.setId("resumeItem");
        resumeItem.setOnAction((final ActionEvent actionEvent) -> value.ifPresent((final Download d) -> System.out.printf("Reprise de %s", d.getName()).println()));
        final MenuItem deleteItem = new MenuItem("Retirer de la liste");
        deleteItem.setId("deleteItem");
        deleteItem.setOnAction((final ActionEvent actionEvent) -> value.ifPresent((final Download d) -> System.out.printf("Suppression de %s", d.getName()).println()));
        //
        contextMenu.setId("contextMenu");
        contextMenu.getItems().add(restartItem);
        contextMenu.getItems().add(new SeparatorMenuItem());
        contextMenu.getItems().add(pauseItem);
        contextMenu.getItems().add(resumeItem);
        contextMenu.getItems().add(new SeparatorMenuItem());
        contextMenu.getItems().add(deleteItem);
    }

    @Override
    protected void updateItem(final Download download, final boolean empty) {
        super.updateItem(download, empty);
        value.ifPresent((final Download d) -> {
            // Retirer l'écouteur de l'ancienne valeur.
            d.progressProperty().removeListener(invalidationListener);
            setContextMenu(null);
        });
        value = Optional.ofNullable(download);
        value.ifPresent((final Download d) -> {
            // Placer l'écouteur sur la nouvelle valeur.
            d.progressProperty().addListener(invalidationListener);
            setContextMenu(contextMenu);
        });
        requestUpdateStyle();
    }

    //
    private final InvalidationListener invalidationListener = (final Observable observable) -> requestUpdateStyle();

    private PauseTransition styleWaitTimer;
    private final Duration styleWaitDuration = Duration.millis(350);

    // Démarrer une mise à jour du style.
    // Comme cette méthode va être appelée régulièrement, on bufferise les appels.
    private void requestUpdateStyle() {
        if (styleWaitTimer == null) {
            styleWaitTimer = new PauseTransition(styleWaitDuration);
            styleWaitTimer.setOnFinished((final ActionEvent actionEvent) -> {
                styleWaitTimer = null;
                updateStyle();
            });
            styleWaitTimer.playFromStart();
        }
    }

    // Mise à jour du style.
    private void updateStyle() {
        final PseudoClass finishedPseudoClass = PseudoClass.getPseudoClass("finished");
        pseudoClassStateChanged(finishedPseudoClass, false);
        value.ifPresent((final Download d) -> {
            final long progress = d.getProgress();
            final long size = d.getSize();
            final boolean enableStyle = (size != -1) && (progress == size);
            pseudoClassStateChanged(finishedPseudoClass, enableStyle);
        });
    }
}

Ainsi que le fichier CSS suivant :

Fichier test.DownloadTableRow.java
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
.download-table-row {    
}
.download-table-row:finished {
    -base-color: greenyellow;
    -fx-font-weight: bold;
    -fx-background-color: linear-gradient(to bottom, derive(-base-color, 50%) 0%, derive(-base-color, -10%) 100%);
}

Et enfin, nous activons notre nouvelle cellule de ligne dans la table en spécifiant la fabrique appropriée :

 
Sélectionnez
1.
tableView.setRowFactory((final TableView<Download> p) -> new DownloadTableRow());

Une fois de plus, l'ajout d'une simple ligne de code peut changer drastiquement le fonctionnement et l'apparence de notre table !

Image non disponible
Figure 47 - Intégration de nos modifications sur les lignes.

VI. Arbres

Cette seconde série de contrôles utilise une unique référence pour stocker la racine de l'arborescence à afficher (même dans le cas d'une TreeTableView). Ces contrôles disposent donc tous de la propriété suivante :

  • root - un objet de type TreeItem<V> contenant le nœud racine de l'arborescence à afficher.

VI-A. Stockage des données

La classe javafx.scene.control.TreeItem<V> est la classe de base permettant de stocker des éléments dans une arborescence graphique. Cette classe n'a rien de graphique en soi ; elle sert juste de conteneur pour construire l'arborescence d'objets V. Par la suite, cette arborescence sera affichée dans le contrôle via des cellules de manière similaire à ce que nous avons vu jusqu'à présent.

À l'heure actuellement, cette classe dispose d'une seule classe fille : javafx.scene.control.CheckBoxTreeItem<V>. Cette seconde classe est une classe prête à l'emploi destinée à produire des arbres contenant des cases à cocher (CheckBox) qui pourront être sélectionnées ou désélectionnées par l'utilisateur. Il faut l'utiliser en conjonction avec la classe cellule CheckBoxTreeCell<V>.

VI-A-1. Propriétés

Les propriétés importantes de la classe TreeItem<V> sont :

  • expanded - indique si cette branche a été déroulée pour afficher ses enfants ;
  • graphic - un nœud graphique qui sera affiché dans la cellule chargée du rendu de cette branche ;
  • leaf - une propriété en lecture seule qui retourne true si cet objet est une feuille dans l'arborescence ;
  • parent - une propriété en lecture seule qui contient une référence sur la branche parente de cet objet ;
  • value - cette propriété contient une référence vers l'objet de type V contenu dans cette branche.

Les propriétés importantes de la classe CheckBoxTreeItem<V> sont :

  • independent - cette propriété permet de spécifier si le fait de cocher cet objet influe sur l'état de son parent ou de ses enfants ;
  • indeterminate - cette propriété spécifie si l'objet supporte l'état non déterminé : les CheckBox dans JavaFX peuvent être configurées pour avoir trois états (sélectionné, non sélectionné ou indéterminé) au lieu de seulement deux (sélectionné ou non sélectionné) ;
  • selected - cette propriété spécifie si l'objet est sélectionné ou non.

VI-A-2. Arbre dynamique

Par défaut, TreeItem<V> demande à créer toute l'arborescence d'objets V en mémoire avant de l'afficher à l'écran. Cependant, dans certains cas, on peut être amené à charger un arbre dynamiquement, c'est-à-dire à le construire en mémoire au fur et à mesure qu'on étend ses branches plutôt que de le charger intégralement au départ.

C'est le cas, par exemple, d'un explorateur de fichiers avec une vue arborescente : une branche représente généralement un répertoire, un disque ou encore un point de montage, tandis qu'une feuille est généralement un fichier, un lien ou un périphérique. Il est hors de question de construire un arbre qui représente intégralement le contenu de tout un système de fichiers qui s'étale sur un ou plusieurs disques ou même sur le réseau :

  • le coût en utilisation mémoire serait trop important pour stocker l'intégralité des fichiers et répertoires, chacun occupant exactement une instance de TreeItem ;
  • Le temps même des opérations nécessaires pour parcourir ou indexer le système de fichiers dans son intégralité serait prohibitif.

Pour ce type d'utilisation, on utilisera donc une construction dynamique de l'arbre : lorsqu'une branche est étendue, on génère ses branches et feuilles filles. Lorsqu'une branche est repliée, on effectue un nettoyage et on vide la liste de ses enfants.

Malheureusement, ici la propriété leaf de la classe TreeItem est en lecture seule, son setter est en accès privé de même que le membre qui stocke la propriété. La documentation de la classe nous indique seulement qu'il est possible de surcharger la méthode isLeaf(), ce qui est un peu contraire au principe d'utilisation des propriétés. Il n'existe donc pas de bonne solution en l'état pour les API javaFX 2.x et 8.

Un hack simple et qui fonctionne (pour le moment) consiste à surcharger la méthode isLeaf() et à ajouter un écouteur sur la propriété expanded de notre TreeItem et ensuite d'agir en conséquence suivant les changements d'état de cette propriété. Un squelette pour créer un tel nœud « dynamique » pour TreeView et TreeTableView serait similaire à :

Code JDK7
Cacher/Afficher le codeSélectionnez
Code JDK8
Cacher/Afficher le codeSélectionnez

Même ainsi, puisque notre surcharge de la méthode isLeaf() est « figée » il n'est pas aisé d'avoir un objet dont l'état leaf varie au fil du temps, car l'API actuelle ne permet pas de faire remonter cette information vers l'affichage de manière dynamique.

Dans notre exemple d'explorateur de fichiers : il vaut mieux supposer que les répertoires sont toujours des branches et ce de manière à pouvoir tout le temps explorer leur contenu. On ne peut pas avoir un répertoire qui est une branche quand il contient des fichiers, mais qui devient une feuille lorsque le dernier fichier qu'il contient est effacé puis qui redevient une branche quand on y crée de nouveaux fichiers.

Une requête a été déposée sur le Jira de JavaFX (enregistrement obligatoire) concernant la modification de l'API TreeView pour permettre l'accès à la propriété leaf de manière plus classique (via un setter ou une propriété en lecture-écriture). Cependant le correctif, s'il survient un jour, est actuellement ciblé sur JavaFX 9.

VI-B. TreeView<V>

Le contrôle TreeView<V> est donc destiné à afficher une arborescence d'objets de type V à l'écran. Dans la configuration par défaut, la racine de l'arbre apparait en haut de l'affichage :

Image non disponible
Figure 48 - Affichage standard d'un TreeView.

Il est possible de configurer ce contrôle de manière à cacher le nœud racine de l'arbre ce qui donne l'illusion que l'arbre graphique dispose de plusieurs racines :

Image non disponible
Figure 49 - Affichage en cachant le nœud racine.

Dans un TreeView, les cellules sont agencées les unes sous les autres comme dans une ListView configurée pour une orientation verticale. Chaque cellule est étendue pour remplir tout l'espace horizontal occupé par l'arbre graphique. Cependant, dans une cellule, le contenu peut être décalé et décoré pour indiquer le niveau de branche sur laquelle se trouve la donnée :

Image non disponible
Figure 50 - Cellules dans un TreeView

VI-B-1. Propriétés

Les propriétés importantes de ce contrôle sont :

  • cellFactory - de type Callback<TreeView<V>, TreeCell<V>> ; une fabrique à cellules qui est utilisée pour produire une cellule destinée à afficher une ligne de l'arbre pour afficher chaque valeur visible ;
  • editable - permet de spécifier si les lignes de l'arbre peuvent être éditées ;
  • editingItem - une propriété en lecture seule qui retourne la branche en train d'être éditée ;
  • expandedItemCount - une propriété en lecture seule qui retourne la somme du nombre de branches étendues et leurs enfants. Le nombre retourné est le nombre total de nœuds potentiellement visibles dans l'arbre ;
  • fixedCellSize - permet de forcer une hauteur commune à toutes les cellules au lieu de calculer la hauteur cellule par cellule. Cette propriété est destinée à améliorer les performances de mise en page. JDK8 ou supérieur ;
  • onEditCancel - un callback appelé lorsque l'utilisateur annule son édition ;
  • onEditCommit - un callback appelé lorsque l'utilisateur valide son édition ;
  • onEditStart - un callback appelé lorsque l'utilisateur démarre son édition ;
  • onScrollTo - un callback appelé lorsque la méthode scrollTo(indice) est invoquée. JDK8 ou supérieur ;
  • root - un objet de type TreeItem<V> contenant le nœud racine de l'arborescence ;
  • selectionModel - gère la sélection dans l'arbre. Généralement, on utilisera le modèle par défaut ;
  • showRoot - spécifie si la racine de l'arborescence doit être affichée ou non.

VI-B-2. Apparence de la flèche

Il est possible de modifier l'apparence de la flèche qui permet de déplier ou de replier une branche en utilisant les CSS. De cette manière, on peut changer la couleur ou même la forme utilisée en spécifiant une nouvelle forme SVG ; il est également possible de remplacer le contenu du nœud par une image.

Par exemple, la feuille de style suivante remplace la flèche habituellement présente par deux images. L'icône en forme de Image non disponible sera affichée quand une branche peut être dépliée tandis que l'icône en forme de Image non disponible sera affichée quand une branche peut être repliée.

Fichier test.TreeView-DisclosureIcon.css
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
.tree-cell  > .tree-disclosure-node > .arrow {
    -fx-background-image: url("treecell-expand.png");
    -fx-padding: 4.5;
    -fx-shape: null;
}
.tree-cell:expanded  > .tree-disclosure-node > .arrow {
    -fx-background-image: url("treecell-contract.png");
    -fx-rotate: 0;
}

Ensuite, nous attachons la feuille de style à notre scène. Les deux images et le fichier CSS sont ici placés dans le même package que le code de lancement de l'application.

 
Sélectionnez
final URL cssURL = getClass().getResource("TreeView-DisclosureIcon.css");
scene.getStylesheets().add(cssURL.toExternalForm());

Désormais la flèche noire est remplacée par deux icônes Image non disponible et Image non disponible :

Image non disponible
Figure 51 - Changement de l'affichage des branches.

VI-B-3. En pratique

Nous allons maintenant réaliser une liste de contacts pour simuler le genre d'affichage qu'on peut trouver dans des logiciels de messagerie instantanée ou de VoIP, par exemple, dans Skype ou encore Yahoo! Messenger.

Dans un vrai logiciel, la liste de nos contacts sera transmise par notre serveur, mais ici nous allons la lire depuis un fichier texte placé dans le projet. Commençons par définir le fichier contenant nos contacts ainsi que leurs catégories.

Fichier test.contacts.txt
Cacher/Afficher le codeSélectionnez

Nous avons également besoin de définir les classes nécessaires au stockage en mémoire. La classe Entity est une classe abstraite parente des classes :

  • Entity.Group - la classe qui sert à définir les catégories de classement des contacts ;
  • Entity.Contact - la classe qui sert à définir un contact. Elle contient diverses informations comme le message du jour ou l'avatar du contact. Cette classe contient également l'énumération Entity.Contact.State qui sert à définir le statut en ligne.
Fichier test.Entity.java, code JDK7
Cacher/Afficher le codeSélectionnez
Fichier test.Entity.java, code JDK8
Cacher/Afficher le codeSélectionnez

Nous allons maintenant charger nos contacts et les afficher dans un TreeView<Entity>. Nous en profitons également pour charger les images qui serviront d'avatar à nos contacts :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
final List<Entity> entities = new LinkedList<>();
try {
    try (final InputStream input = getClass().getResourceAsStream("contacts.txt")) {
        Entity.Group lastGroup = null;
        try (final LineNumberReader in = new LineNumberReader(new InputStreamReader(input))) {
            for (String line = in.readLine(); line != null; line = in.readLine()) {
                line = line.trim();
                if (line.isEmpty()) {
                    continue;
                }
                final String[] tokens = line.split("\\|");
                if (tokens.length == 1) {
                    final Entity.Group group = new Entity.Group();
                    group.setDisplayName(tokens[0]);
                    entities.add(group);
                    lastGroup = group;
                } else {
                    if (lastGroup == null) {
                        continue;
                    }
                    final Entity.Contact contact = new Entity.Contact();
                    contact.setDisplayName(tokens[0]);
                    contact.setState(Entity.Contact.State.valueOf(tokens[1]));
                    contact.setStatusMessage(tokens[2]);
                    final String avatarPath = "images/"+tokens[3];
                    final URL avatarURL = getClass().getResource(avatarPath);
                    final Image avatarImage = (avatarURL == null) ? null : new Image(avatarURL.toExternalForm());
                    contact.setAvatar(avatarImage);
                    lastGroup.getChildren().add(contact);
                    entities.add(contact);
                }
            }
        }
    }
} catch (IOException | IllegalArgumentException | IndexOutOfBoundsException ex) {
    Logger.getLogger(getClass().getName()).log(Level.SEVERE, ex.getMessage(), ex);
}
// Peuplement de la structure de l'arbre.
final TreeItem<Entity> rootItem = new TreeItem<>();
TreeItem<Entity> groupItem = null;
while (!entities.isEmpty()) {
    final Entity currentEntity = entities.remove(0);
    final TreeItem<Entity> currentItem = new TreeItem<>(currentEntity);
    if (currentEntity instanceof Entity.Group) {
        rootItem.getChildren().add(currentItem);
        currentItem.setExpanded(true);
        groupItem = currentItem;
    } else if (groupItem != null) {
        groupItem.getChildren().add(currentItem);
    }
}
final TreeView<Entity> treeView = new TreeView<>();
treeView.setRoot(rootItem);
treeView.setShowRoot(false);
final StackPane root = new StackPane();
root.getChildren().add(treeView);
final Scene scene = new Scene(root);
primaryStage.setTitle("TreeView");
primaryStage.setWidth(300);
primaryStage.setHeight(450);
primaryStage.setScene(scene);

Pour le moment, notre arbre se contente d'un affichage textuel classique : seules sont affichées les valeurs retournées par la méthode toString() des objets contenus dans l'arbre :

Image non disponible
Figure 52 - Affichage par défaut.

Nous avons donc deux types d'objets à représenter : les groupes et les contacts.

  • Pour les groupes, nous allons nous contenter de quelque chose de simple : une ligne de texte contenant le nom du groupe et un indicateur qui affiche le nombre de contacts en ligne par rapport au nombre total de membres du groupe. Nous utiliserons directement du code Java dans la cellule.
  • Pour les contacts, nous allons avoir un affichage plus complexe : le nom ou surnom du contact, l'avatar, une icône montrant le statut de connexion et le message du jour du contact. Ici, compte tenu du fait que c'est un peu plus complexe à mettre en place, nous allons à nouveau utiliser du FXML et les CSS pour éviter de vous noyer dans du code servant uniquement à monter une interface graphique.
Image non disponible
Figure 53 - Création de la cellule dans SceneBuilder.

Il est très facile de définir la future apparence de notre cellule en utilisant SceneBuilder ou en écrivant directement le FXML suivant :

Fichier test.ContactRenderer.fxml
Cacher/Afficher le codeSélectionnez

Nous allons jouer avec les CSS pour modifier l'apparence de la région statusIndicator en fonction du statut en ligne du contact. Bien que cette région soit initialement de forme carrée, nous pouvons lui donner des bords arrondis grâce aux CSS de manière à lui donner une forme de diode ou d'orbe. Nous pouvons faire varier sa couleur via la variable -base-color. Nous aurions pu tout aussi bien définir des styles pour chaque état du statut de connexion et utiliser des images bitmap prégénérées qui auraient été référencées dans la feuille de style pour chaque style.

Fichier test.ContactRenderer.css
Cacher/Afficher le codeSélectionnez

Et enfin, voici le contrôleur du FXML : lorsque ce dernier reçoit un nouveau contact, il adapte son affichage pour présenter les informations à l'écran.

Fichier test.ContactRendererController.java, code JDK7
Cacher/Afficher le codeSélectionnez
Fichier test.ContactRendererController.java, code JDK8
Cacher/Afficher le codeSélectionnez

Maintenant que nous avons notre renderer de contact, nous définissons une classe cellule qui se chargera d'afficher correctement l'entité actuelle :

  • lorsque nous avons un groupe, nous utilisons directement la propriété text de la cellule, sans aucun graphique ;
  • lorsque nous avons un contact, le texte est mis à null et nous utilisons notre renderer en tant que graphique de la cellule.
Fichier test.EntityTreeCell.java, code JDK7
Cacher/Afficher le codeSélectionnez
Fichier test.EntityTreeCell.java, code JDK8
Cacher/Afficher le codeSélectionnez

Nous devons alors insérer la ligne de code suivante (une seule et unique) dans notre code principal pour activer notre nouvel affichage :

 
Sélectionnez
1.
treeView.setCellFactory(EntityTreeCell.forTreeView());

Le résultat obtenu est quand même plus intéressant !

Image non disponible
Figure 54 - Affichage final.

VI-C. TreeTableView<V>

Note : TreeTableView étant un contrôle qui n'est disponible qu'à partir de JavaFX 8 ; le code de cette section sera donc uniquement au format JDK8.

TreeTableView est un contrôle qui affiche un arbre dans la première colonne d'une table. Il se comporte comme TreeView pour ce qui est de la structure arborescente des données et des extensions/contractions des branches, mais aussi avec les mêmes subtilités liées aux besoins en fabriques de données pour les colonnes que celles que nous avons vues à propos de TableView.

Image non disponible
Figure 55 - Un TreeTableView.

Tout comme c'était le cas pour TableView, nous serons amenés à manipuler une seconde classe tout aussi importante : javafx.scene.control.TreeTableColumn<V, T>. Chaque colonne de la table opère sur deux types :

  • V qui est le type de l'objet contenu dans la table ;
  • T qui est le type de l'objet à afficher dans la colonne.

VI-C-1. Propriétés

Les propriétés importantes propres à ce contrôle sont les suivantes :

  • columnResizePolicy - un callback qui permet de spécifier si les colonnes prennent tout l'espace horizontal visible ou se contentent de leur taille prédéfinie. La class TreeTableView contient deux constantes prédéfinies qu'il est conseillé d'utiliser :
    • CONSTRAINED_RESIZE_POLICY - les colonnes prennent tout l'espace horizontal visible,
    • UNCONSTRAINED_RESIZE_POLICY - utilisation des tailles prédéfinies ;
  • comparator - une propriété en lecture seule qui contient un objet de type Comparator<V> lié au tri en cours sur la table ;
  • editable - permet de spécifier si les cellules de la table peuvent être éditées ;
  • editingCell - une propriété en lecture seule indiquant la position de la cellule en train d'être éditée ;
  • expandedItemCount - une propriété en lecture seule qui retourne la somme du nombre de branches étendues et leurs enfants. Le nombre retourné est le nombre total de nœuds potentiellement visibles dans l'arbre ;
  • fixedCellSize - permet de forcer une hauteur commune à toutes les cellules au lieu de calculer la hauteur cellule par cellule. Cette propriété est destinée à améliorer les performances de mise en page ;
  • items - une ObservableList<V> contenant les objets à afficher ;
  • onScrollToColumn - un callback appelé lorsque la méthode scrollToColumn(indice) ou scrollToColumn(colonne) est invoquée ;
  • onScrollTo - un callback appelé lorsque la méthode scrollTo(indice) ou scrollTo(valeur) est invoquée ;
  • onSort - un callback appelé lorsque le contenu du contrôle est trié ;
  • placeHolder - un nœud graphique à afficher lorsque la table n'a pas de contenu ;
  • rowFactory - une fabrique qui génère une cellule destinée à représenter une ligne entière de la table. Généralement, on utilisera la fabrique par défaut ;
  • selectionModel - gère la sélection dans la table. Généralement, on utilisera le modèle par défaut ;
  • sortPolicy - la politique de tri à appliquer sur le contenu de la table ;
  • tableMenuButtonVisible - permet d'afficher un bouton autorisant l'utilisateur à accéder à un menu contrôlant la présence ou non de certaines colonnes ;
  • treeColumn - référence la colonne qui affiche un arbre (par défaut la première colonne de la table).

Que nous complétons avec les propriétés de la classe TreeTableColumn<V, T> :

  • cellFactory - de type Callback<TreeTableColumn<V, T>, TreeTableCell<V, T>> ; une fabrique à cellules qui est utilisée pour produire une cellule destinée à afficher chaque valeur T de la colonne associée à chaque valeur V de la table ;
  • cellValueFactory - très importante et à ne pas confondre avec la précédente : une fabrique qui, pour chaque valeur V de la table retourne une ObservableValue<T> pour cette colonne. Cette fabrique sert donc à peupler les valeurs de la colonne à partir de celles de la table ;
  • onEditCancel - un callback appelé lorsque l'utilisateur annule son édition ;
  • onEditCommit - un callback appelé lorsque l'utilisateur valide son édition ;
  • onEditStart - un callback appelé lorsque l'utilisateur démarre son édition ;
  • sortType - indique si la colonne est triée de manière ascendante ou descendante quand un tri est appliqué sur la table ;
  • treeTableView - une propriété en lecture seule qui contient une référence vers la table parente.

VI-C-2. En pratique

Nous allons réaliser un mini-explorateur de fichiers qui permettra d'afficher les détails de la structure arborescente d'un répertoire. Nous allons en profiter pour délaisser (un petit peu) la vieillissante classe java.io.File et nous intéresser aux NIO2 introduits dans le JDK7 avec java.nio.file.Path et toutes les classes associées.

Commençons par nous créer une classe nommée MyFile qui servira de façade aux appels vers la couche NIO2… et également vers Swing (!). Nous allons en effet récupérer quelques informations en provenance de l'OS qui vont nous être fournies par la classe javax.swing.filechooser.FileSystemView . Cette classe est utilisée par JFileChooser, le sélectionneur de fichiers de Swing, pour récupérer quelques données natives telles que l'icône représentant le fichier ou son type.

Note : à cause de cette dépendance, ce projet ne pourra donc pas fonctionner dans les environnements sur lesquels Swing n'est pas présent (ex. : Java Embedded sur Raspberry Pi).

Également, pour conserver un code relativement simple à lire, nous ne monitorerons pas les modifications sur le fichier ou le répertoire. Cela aurait demandé la création et la mise en place de watch services sur les répertoires avec toute la gestion de tâches asynchrones qui va avec, ce qui est un peu en dehors du but de ce tutoriel.

Fichier test.MyFile.java
Cacher/Afficher le codeSélectionnez

Bien entendu, nous devons stocker ces objets dans des instances de TreeItem<MyFile>. Cependant, comme je vous l'ai indiqué précédemment, en général on ne charge pas entièrement une arborescence de fichiers en mémoire. Nous allons donc utiliser des nœuds dynamiques dans notre arbre !

Fichier test.MyFileTreeItem.java
Cacher/Afficher le codeSélectionnez

Maintenant nous allons charger un répertoire (par exemple, celui contenant ce projet) et l'afficher dans un TreeTableView. La suite est assez simple et ressemble à ce que nous avons précédemment fait pour TableView en ce qui concerne les fabriques de données :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
final TreeTableView treeTableView = new TreeTableView();
treeTableView.setColumnResizePolicy(TreeTableView.CONSTRAINED_RESIZE_POLICY);
//
final TreeTableColumn<MyFile, String> nameColumn = new TreeTableColumn<>("Nom");
nameColumn.setCellValueFactory((TreeTableColumn.CellDataFeatures<MyFile, String> p) -> {
    final MyFile file = p.getValue().getValue();
    return new SimpleStringProperty(file.getSystemDisplayName());
});
//
final TreeTableColumn<MyFile, String> typeColumn = new TreeTableColumn<>("Type");
typeColumn.setCellValueFactory((TreeTableColumn.CellDataFeatures<MyFile, String> p) -> {
    final MyFile file = p.getValue().getValue();
    return new SimpleStringProperty(file.getSystemTypeDescription());
});
//
final TreeTableColumn<MyFile, Long> sizeColumn = new TreeTableColumn<>("Taille");
sizeColumn.setCellValueFactory((TreeTableColumn.CellDataFeatures<MyFile, Long> p) -> {
    final MyFile file = p.getValue().getValue();
    return new SimpleObjectProperty<>(file.getSize());
});
//
final TreeTableColumn<MyFile, FileTime> createdColumn = new TreeTableColumn<>("Création");
createdColumn.setCellValueFactory((TreeTableColumn.CellDataFeatures<MyFile, FileTime> p) -> {
    final MyFile file = p.getValue().getValue();
    return new SimpleObjectProperty<>(file.getCreationTime());
});
//
final TreeTableColumn<MyFile, FileTime> modifiedColumn = new TreeTableColumn<>("Modifié");
modifiedColumn.setCellValueFactory((TreeTableColumn.CellDataFeatures<MyFile, FileTime> p) -> {
    final MyFile file = p.getValue().getValue();
    return new SimpleObjectProperty<>(file.getModificationTime());
});
//
final TreeTableColumn<MyFile, FileTime> lastAccessColumn = new TreeTableColumn<>("Dernier accès");
lastAccessColumn.setCellValueFactory((TreeTableColumn.CellDataFeatures<MyFile, FileTime> p) -> {
    final MyFile file = p.getValue().getValue();
    return new SimpleObjectProperty<>(file.getLastAccessTime());
});
//
final TreeTableColumn<MyFile, Boolean> readableColumn = new TreeTableColumn<>("Lisible ?");
readableColumn.setCellValueFactory((TreeTableColumn.CellDataFeatures<MyFile, Boolean> p) -> {
    final MyFile file = p.getValue().getValue();
    return new SimpleBooleanProperty(file.isReadable());
});
//
final TreeTableColumn<MyFile, Boolean> writableColumn = new TreeTableColumn<>("Modifiable ?");
writableColumn.setCellValueFactory((TreeTableColumn.CellDataFeatures<MyFile, Boolean> p) -> {
    final MyFile file = p.getValue().getValue();
    return new SimpleBooleanProperty(file.isWritable());
});
//
final TreeTableColumn<MyFile, Boolean> executableColumn = new TreeTableColumn<>("Exécutable ?");
executableColumn.setCellValueFactory((TreeTableColumn.CellDataFeatures<MyFile, Boolean> p) -> {
    final MyFile file = p.getValue().getValue();
    return new SimpleBooleanProperty(file.isExecutable());
});
executableColumn.setCellFactory(CheckBoxTreeTableCell.forTreeTableColumn(executableColumn));
//
treeTableView.getColumns().setAll(nameColumn, typeColumn, sizeColumn, createdColumn, modifiedColumn, lastAccessColumn, readableColumn, writableColumn, executableColumn);
//
final Path rootPath = new File(System.getProperty("user.dir")).toPath();
final MyFile rootFile = new MyFile(rootPath);
final TreeItem<MyFile> rootItem = new MyFileTreeItem(rootFile);
treeTableView.setRoot(rootItem);
//
final StackPane root = new StackPane();
root.getChildren().add(treeTableView);
final Scene scene = new Scene(root);
primaryStage.setScene(scene);
primaryStage.setWidth(950);
primaryStage.setTitle("TreeTableView");

Initialement notre affichage apparait avec la seule racine visible, mais une fois la branche dépliée, vous devriez obtenir un affichage similaire à :

Image non disponible
Figure 56 - Affichage standard.
VI-C-2-a. Booléens

Vous connaissez désormais l'astuce ! Pour afficher des cases à cocher sur les colonnes contenant des valeurs booléennes, l'API met à disposition des cellules prêtes à l'emploi. Ici c'est la classe javafx.scene.control.cell.CheckBoxTreeTableCell qu'il faut utiliser. Si nous insérons les lignes suivantes dans notre code :

 
Sélectionnez
1.
2.
3.
readableColumn.setCellFactory(CheckBoxTreeTableCell.forTreeTableColumn(readableColumn));
writableColumn.setCellFactory(CheckBoxTreeTableCell.forTreeTableColumn(writableColumn));
executableColumn.setCellFactory(CheckBoxTreeTableCell.forTreeTableColumn(executableColumn));

La différence saute tout de suite aux yeux :

Image non disponible
Figure 57 - Insertion de cellules pour les valeurs booléennes.

Note : mes tests sont effectués sous Windows donc les fichiers auxquels j'accède ont tous les droits d'accès. De même, mon système est en anglais, ce qui explique le contenu de la seconde colonne.

VI-C-2-b. Icônes

Nous allons maintenant créer de nouveaux types de cellules pour afficher les autres données. Commençons par la première colonne, celle qui affiche le nom du fichier et arrangeons-nous pour y afficher également les icônes des fichiers et des dossiers.

Fichier test.MyFileNameTreeTableCell.java
Cacher/Afficher le codeSélectionnez

Nous activerons cette nouvelle cellule en ajoutant la ligne suivante à notre code :

 
Sélectionnez
1.
nameColumn.setCellFactory(MyFileNameTreeTableCell.forTreeTableColumn());

Ce qui nous donne désormais l'affichage suivant :

Image non disponible
Figure 58 - Ajout des icônes des fichiers.
VI-C-2-c. Date

Occupons-nous désormais des affichages des dates. Ici nos appels aux méthodes statiques de la classe Files dans notre classe MyFile retournent des objets de type FileTime. Il s'agit d'une nouvelle classe introduite dans le JDK8 et qui utilise la nouvelle API de temps. Heureusement pour nous, il nous est possible de les convertir en millisecondes depuis l'Epoch (la date de référence qui marque le début du calendrier UNIX) et ensuite de les convertir en Date Java puis en texte via les formateurs habituels :

Fichier test.FileTimeTreeTableCell.java
Cacher/Afficher le codeSélectionnez

Que nous activons via les lignes de code suivantes :

 
Sélectionnez
1.
2.
3.
createdColumn.setCellFactory(FileTimeTreeTableCell.forTreeTableColumn());
modifiedColumn.setCellFactory(FileTimeTreeTableCell.forTreeTableColumn());
lastAccessColumn.setCellFactory(FileTimeTreeTableCell.forTreeTableColumn());

Avec pour résultat :

Image non disponible
Figure 59 - Ajout de la prise en charge des dates.
VI-C-2-d. Taille

Enfin nous allons terminer cet aperçu en créant une cellule qui permettra de formater correctement la taille du fichier :

Fichier test.MyFileSizeTreeTableCell.java
Cacher/Afficher le codeSélectionnez

L'activation se résume une fois de plus à une simple ligne :

 
Sélectionnez
1.
sizeColumn.setCellFactory(MyFileSizeTreeTableCell.forTableColumn());

Et le résultat donne :

Image non disponible
Figure 60 - Ajout du support de la taille des fichiers.

VII. Conclusion

Nous avons fait un rapide tour d'horizon des contrôles JavaFX actuellement disponibles et qui utilisent l'API Cell. Bien que nous nous soyons attachés à voir des cas particuliers pour chacun de ces contrôles, les techniques présentées ici et là pour un contrôle donné sont généralement applicables aux autres. C'est désormais à votre tour de jouer pour rendre vos applications plus riches et vivantes !

VIII. Liens

  • Flowless - une nouvelle implémentation d'un gestionnaire de vue virtualisée. Propose également un comparateur de performances entre cette nouvelle implémentation et celles de l'API JavaFX.

IX. 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 Claude Leloup et f-leb pour leurs corrections orthographiques.

X. Annexe

X-A. Code source et exemples

Vous pouvez retrouver un projet NetBeans contenant les tests et exemples se rapportant à cet article sur https://fabrice-bouye.developpez.com/tutoriels/javafx/customisation-controle-virtualise-api-cell-javafx/fichiers/code_source_javafx_cell.zip

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

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 © 2014 Fabrice Bouyé. Aucune reproduction, même partielle, ne peut être faite de ce site ni 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.