I. Introduction▲
Découpler la définition des interfaces utilisateur du code n'a rien d'un concept nouveau : inclure des pages et des pages entières de code dans un projet pour définir ne serait-ce qu'un simple formulaire avec un bouton de validation correctement positionné est probablement une étape par laquelle nous sommes tous passés… sauf peut-être les habitués de Visual Studio puisque Microsoft prit ce virage très tôt dans la conception de ses outils de développement. Ce n'est pas pour rien que les langages de définition d'interface graphique par balisage (User Interface Markup Language) fleurissent sur la toile.
Côté Java, les choses ont longtemps été à la traine : même si NetBeans et Eclipse disposent désormais d'éditeurs graphiques performants pour Swing et leurs propres application frameworks, l'accouchement a été plutôt difficile et il s'agit dans tous les cas d'une surcouche rajoutée par-dessus l'API standard. En essayant d'intégrer une prise en charge directe par la plateforme, Oracle a tout d'abord effectué un premier essai avec FXD dans JavaFX 1.x. Le FXD permettait de décrire des UI dans un langage de script simple qui était un sous-ensemble du langage JavaFX Script utilisé dans l'API de l'époque. Le problème évident était qu'il s'agissait d'un nouveau langage à part entière, la plateforme est restée peu populaire.
Avec le retour vers Java dans JavaFX 2.x, et l'ouverture des runtimes à tous les langages tournant sur la JVM, Oracle a, au contraire, décidé de s'inspirer de ce qui se faisait déjà sur le marché : le MXML largement utilisé par Flex et Flash d'Adobe ou encore le XAML de Microsoft destiné à Silverlight et WPF. Voici donc venir le FXML, un nouveau dérivé du langage de balisage XML, directement pris en charge par les runtimes JavaFX et accompagné de nouveaux outils.
II. Les Bases▲
Un fichier au format FXML est donc un document écrit en XML contenant le descriptif d'une arborescence graphique dans l'API SceneGraph. Un FXML tout simple tel que créé par NetBeans ou SceneBuilder ressemblera au code suivant :
2.
3.
4.
5.
6.
7.
8.
9.
10.
<?xml version="1.0" encoding="UTF-8"?>
<?import java.lang.*?>
<?import java.util.*?>
<?import javafx.scene.*?>
<?import javafx.scene.control.*?>
<?import javafx.scene.layout.*?>
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml">
</AnchorPane>
L'arborescence SceneGraph ne contient rien de plus qu'un simple layout de type AnchorPane et dont les dimensions ont été mises à 600 x 400.
II-A. Entête▲
Comme tout fichier XML, l'entête d'un fichier FXML doit être :
<?xml version="1.0" encoding="UTF-8"?>
Évidemment, le fichier doit être au format texte et encodé à la valeur appropriée.
II-B. Imports▲
À la suite de l'entête, on trouvera une série d'imports de packages similaires à ceux qu'on peut trouver dans le code d'une classe Java :
2.
3.
4.
5.
<?import java.lang.*?>
<?import java.util.*?>
<?import javafx.scene.*?>
<?import javafx.scene.control.*?>
<?import javafx.scene.layout.*?>
Il est possible d'importer n'importe quel package Java qui se trouve sur le CLASSPATH à l'exécution, y compris les vôtres ou ceux de bibliothèques externes.
Ces déclarations sont optionnelles : comme dans du code Java, il est en effet possible d'utiliser les noms longs des classes (c'est-à-dire l'arborescence des packages suivie du nom de la classe) en lieu et place du nom court (uniquement le nom de la classe).
II-C. Racine▲
Chaque fichier FXML dispose d'une balise racine qui peut être n'importe quel nœud graphique de l'API SceneGraph ou même des nœuds customisés ou provenant de bibliothèques externes. Comme le FXML est avant tout destiné à décrire des bouts d'interface graphique, il vaut cependant mieux que la balise racine soit un nœud du SceneGraph, cependant, en théorie, vous pouvez aussi charger des classes non graphiques.
La racine est la seule balise dans laquelle on peut et on doit déclarer l'attribut xmlns:fx.
2.
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml">
</AnchorPane>
La balise porte le nom de la classe à utiliser tel qu'écrit dans l'API et avec la même casse. En général, dans la plupart des cas, mieux vaut se contenter d'utiliser un AnchorPane comme balise racine du FXML, cela vous permet de positionner vos sous-nœuds comme bon vous semble.
Outre la déclaration de son id, la définition de xmlns:fx et la description des propriétés du nœud (ici prefWidth et prefHeight), si le FXML dispose également d'un contrôleur, la balise racine peut contenir également une définition de l'attribut fx:controller qui définit le nom long (package + nom de classe) de la classe du contrôleur. Nous y reviendrons plus en détail dans un chapitre ultérieur.
2.
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml" fx:controller="test.TestController">
</AnchorPane>
II-D. Charger le FXML▲
Pour charger le fichier FXML ainsi créé, il suffit de résoudre l'URL du fichier via le mécanisme du chargement de ressources habituel en Java (voir ClassLoader) et de créer une nouvelle instance de javafx.fxml.FXMLLoader sur laquelle on va appeler la méthode load(). Cette méthode retournera une instance correspondant au nœud racine décrit dans notre fichier. Si l'URL n'est pas correcte, la méthode load() lèvera une IllegalStateException.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
public final class Main extends Application {
@Override
public void start(final Stage primaryStage) {
try {
// Localisation du fichier FXML.
final URL url = getClass().getResource("test.fxml");
// Création du loader.
final FXMLLoader fxmlLoader = new FXMLLoader(url);
// Chargement du FXML.
final AnchorPane root = (AnchorPane) fxmlLoader.load();
// Création de la scène.
final Scene scene = new Scene(root, 300, 250);
primaryStage.setScene(scene);
} catch (IOException ex) {
System.err.println("Erreur au chargement: " + ex);
}
primaryStage.setTitle("Test FXML");
primaryStage.show();
}
public static void main(String[] args) {
launch(args);
}
}
Ce qui au final donne l'affichage suivant qui n'est pas très excitant en soi, mais c'est normal, notre fichier FXML ne contient rien en dehors du nœud racine :
Comme je vous le disais tantôt, on peut, en théorie, charger une racine qui n'est pas un nœud graphique d'où le fait que la méthode load() retourne une instance de Object plutôt que de Node.
III. Définir une arborescence▲
Nous allons maintenant nous attacher à remplir notre fichier FXML de manière à afficher un peu plus de contenu.
III-A. Étendre la structure▲
Les sous-balises des nœuds qui doivent être inclus dans votre UI se déclarent de la même manière que la balise racine : en utilisant le nom de la classe en respectant la casse. Leur agencement dépend cependant des propriétés propres à chacune des classes parentes utilisées. Par exemple, la plupart des layouts ont une propriété children qui est de type ObservableList<Node>. Rajouter des sous-nœuds dans notre racine revient donc à écrire :
2.
3.
4.
5.
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml">
<children>
<!--Lister les sous-noeuds ici. -->
</children>
</AnchorPane>
Par exemple :
2.
3.
4.
5.
6.
7.
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml">
<children>
<Button layoutX="14.0" layoutY="14.0" mnemonicParsing="false" text="Button" />
<Button layoutX="14.0" layoutY="46.0" mnemonicParsing="false" text="Button" />
<Button layoutX="14.0" layoutY="77.0" mnemonicParsing="false" text="Button" />
</children>
</AnchorPane>
La plupart des nœuds graphiques parents, utilisent également l'annotation @DefaultProperty sur leur propriété qui permet de spécifier leur contenu. Cette annotation permet d'éviter de spécifier un niveau de balise dans l'écriture du FXML. Ainsi, étant donné que children est la propriété par défaut de la classe AnchorPane, il est tout à fait possible d'écrire le contenu en omettant les balises <children> sans pour autant que cela ne cause d'erreur au chargement du fichier :
2.
3.
4.
5.
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml">
<Button layoutX="14.0" layoutY="14.0" mnemonicParsing="false" text="Button" />
<Button layoutX="14.0" layoutY="46.0" mnemonicParsing="false" text="Button" />
<Button layoutX="14.0" layoutY="77.0" mnemonicParsing="false" text="Button" />
</AnchorPane>
À défaut d'être joli, notre affichage devient tout de suite bien plus intéressant :
III-B. Appeler des propriétés▲
On peut remarquer dans cet exemple qu'on utilise des attributs dans les balises pour faire des nouveaux appels à des propriétés ; cette fois-ci, des propriétés qui font partie de la classe Button : layoutX, layoutY, mnemonicParsing et text. Ces attributs sont nommés exactement comme les propriétés qu'ils ciblent en respectant la casse :
<Button layoutX="14.0" layoutY="14.0" mnemonicParsing="false" text="Button" />
On peut également utiliser des balises au lieu d'attributs pour définir les propriétés, mais évidemment le code XML en devient plus verbeux et moins facile à appréhender :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
<Button>
<layoutX>
<Double fx:value="14.0"/>
</layoutX>
<layoutY>
<Double fx:value="14.0"/>
</layoutY>
<mnemonicParsing>
<Boolean fx:value="false"/>
</mnemonicParsing>
<text>
<String fx:value="Button"/>
</text>
</Button>
III-C. Appeler des propriétés statiques▲
Nous allons maintenant placer nos boutons dans un layout permettant de faciliter leur placement à l'écran :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml">
<children>
<VBox prefHeight="200.0" prefWidth="100.0" spacing="6.0" AnchorPane.bottomAnchor="6.0" AnchorPane.leftAnchor="6.0" AnchorPane.rightAnchor="6.0" AnchorPane.topAnchor="6.0">
<children>
<Button maxHeight="1.7976931348623157E308" maxWidth="1.7976931348623157E308" mnemonicParsing="false" text="Button" VBox.vgrow="ALWAYS" />
<Button mnemonicParsing="false" text="Button" />
<Button mnemonicParsing="false" text="Button" />
</children>
</VBox>
</children>
</AnchorPane>
Le layout VBox est une boite verticale qui place tous ses éléments en colonne. Ses quatre côtés sont ancrés sur les bordures de l'AnchorPane qui sert de racine au document. Désormais, le premier bouton voit sa hauteur et sa largeur grandir ou diminuer pour qu'il remplisse tout l'espace occupé par la boite verticale.
Nous pouvons voir que la balise VBox ainsi que la première balise Button contiennent des attributs qui ne sont pas des accès aux propriétés de ces deux classes :
2.
3.
AnchorPane.bottomAnchor="6.0" AnchorPane.leftAnchor="6.0" AnchorPane.rightAnchor="6.0" AnchorPane.topAnchor="6.0"
[...]
VBox.vgrow="ALWAYS"
Grosso modo, on peut considérer que lorsque le FXML sera chargé en mémoire, l'API effectuera les appels aux méthodes statiques suivantes :
2.
3.
4.
5.
6.
AnchorPane.setTopAnchor(vbox, 6.0);
AnchorPane.setLeftAnchor(vbox, 6.0);
AnchorPane.setRightAnchor(vbox, 6.0);
AnchorPane.setBottomAnchor(vbox, 6.0);
[...]
VBox.setVgrow(button, Priority.ALWAYS);
Ces éléments sont appelés des propriétés « statiques » ou propriétés « attachées » ; elles ne proviennent pas de l'objet lui-même, mais de son conteneur parent et n'ont vraiment de sens que par rapport au contexte de leur utilisation. Par exemple, définir AnchorPane.bottomAnchor="6.0" dans le code de la balise Button, n'aurait eu aucun effet au final.
De plus, on peut voir que j'ai, cette fois-ci, utilisé une valeur tirée d'une enum pour la valeur de l'attribut VBox.vgrow dans la balise Button. Cela vous montre que le chargement du FXML peut résoudre des types de valeurs un peu plus complexes que de simples nombres, booléens ou chaine de caractères. Si une valeur non définie dans l'enum Priority avait été utilisée à la place, le chargement du FXML aurait levé une exception de type InvocationTargetException.
III-D. Utiliser des classes ne provenant pas de l'API▲
Dans du FXML, vous pouvez sans problème utiliser des classes qui ne sont pas parties de l'API. Certaines limitations s'appliquent lors de l'utilisation de nœuds autres que ceux de l'API :
- il faut qu'il y ait eu un import du package contenant la classe au début du FXML (ou alors, utiliser le nom long de la classe) ;
- la classe doit avoir un constructeur par défaut (sans argument) accessible (public) ;
- et bien sûr à l'exécution, le bytecode de cette classe doit être accessible sur le CLASSPATH.
Ces restrictions s'appliquent tant pour la déclaration en balise racine que pour la déclaration en sous-balise. Si la classe n'est pas résolue au chargement du FXML, une exception de type javafx.fxml.LoadException sera levée.
Si les propriétés de vos classes sont correctement décrites, vous pouvez également les utiliser depuis le FXML en déclarant des attributs correspondants dans les balises.
Il est aussi possible d'utiliser des classes qui ne sont pas du tout des nœuds graphiques, ce qui peut être utile quand on doit remplir le contenu d'une ListView ou d'une ComboBox avec des valeurs par défaut. Prenons, par exemple, la classe suivante qui définit une voiture avec une propriété brand qui contient la marque de la voiture :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
package test;
import javafx.beans.property.SimpleStringProperty;
import javafx.beans.property.StringProperty;
public class Car {
// Définition de la propriété brand.
private final StringProperty brand = new SimpleStringProperty(this, "brand", null);
// Getter.
public final String getBrand() {
return brand.get();
}
// Setter.
public final void setBrand(final String value) {
brand.set(value);
}
// Accès à la propriété.
public final StringProperty brandProperty() {
return brand;
}
}
Il est tout à fait possible d'initialiser des instances de la classe Car dans un fichier FXML pour remplir une ComboBox :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
<?xml version="1.0" encoding="UTF-8"?>
<?import java.lang.*?>
<?import java.util.*?>
<?import javafx.collections.*?>
<?import javafx.scene.*?>
<?import javafx.scene.control.*?>
<?import javafx.scene.layout.*?>
<?import test.*?>
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml">
<children>
<ComboBox layoutX="14.0" layoutY="14.0">
<items>
<FXCollections fx:factory="observableArrayList">
<Car brand="Peugeot"/>
<Car brand="Renault"/>
<Car brand="Citroën"/>
</FXCollections>
</items>
</ComboBox>
</children>
</AnchorPane>
Ce qui donne le résultat suivant :
Bon d'accord, on ne voit que des chaines de texte dans le style test.Car@6bab735a. C'est tout à fait normal puisque nous n'avons pas mis de cellule appropriée sur la ComboBox pour afficher des instances de Car. Mais si vous rajoutez la méthode suivante dans la classe Car, alors vous verrez que les objets listés contiennent bien les valeurs que nous leur avons données :
2.
3.
4.
@Override
public String toString() {
return getBrand();
}
C'est tout de même mieux comme cela, non ?
Nous pouvons remarquer plusieurs choses :
- nous avons importé deux nouveaux packages qui ne sont pas liés au SceneGraph : le package javafx.collections et le package test ;
- nous avons effectivement chargé trois instances de la class test.Car et nous avons initialisé directement le contenu de la propriété brand depuis le FXML !
- Afin de remplir la propriété items de la classe ComboBox, nous avons dû créer une nouvelle instance de ObservableList.
Certaines propriétés comme children sur les layouts permettent de faire des déclarations implicites sans devoir manuellement créer une nouvelle instance de la classe ObservableList. Apparemment, ce n'est pas encore le cas pour la propriété items de la classe ComboBox et donc j'ai dû manuellement faire une telle déclaration. Si un jour, une telle déclaration implicite est acceptée par le loader FXML, il suffira alors de faire :
2.
3.
4.
5.
6.
7.
<ComboBox layoutX="14.0" layoutY="14.0">
<items>
<Car brand="Peugeot"/>
<Car brand="Renault"/>
<Car brand="Citroën"/>
</items>
</ComboBox>
Il ne faut pas hésiter à poster des Request for Enhancement sur le Java Bug Database d'Oracle et le Java Bug System de l'OpenJDK pour obtenir de telles améliorations.
III-E. Charger des images▲
Pour charger et afficher une image, on a besoin de deux choses, tout comme dans le SceneGraph :
- une instance de la classe Image qui contient notre bitmap chargée en mémoire ;
- et une instance du nœud graphique ImageView pour l'afficher.
Nous nous retrouvons donc avec le FXML suivant qui modifie la propriété graphic du bouton et qui cache son texte par la même occasion :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
<?xml version="1.0" encoding="UTF-8"?>
<?import java.lang.*?>
<?import java.util.*?>
<?import javafx.scene.*?>
<?import javafx.scene.control.*?>
<?import javafx.scene.image.*?>
<?import javafx.scene.layout.*?>
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml">
<children>
<Button contentDisplay="GRAPHIC_ONLY" layoutX="14.0" layoutY="14.0" mnemonicParsing="false" text="Button">
<graphic>
<ImageView id="logo" pickOnBounds="true">
<image>
<Image url="@logo.png" preserveRatio="true" smooth="true" />
</image>
</ImageView>
</graphic>
</Button>
</children>
</AnchorPane>
Nous voyons que nous avons dû inclure le package supplémentaire javafx.scene.image de manière à pouvoir utiliser ces classes. Au fait, j'ai à nouveau utilisé une valeur d'une enum, ici javafx.scene.control.ContentDisplay, pour l'attribut contentDisplay de la balise Button. Lorsque vous écrivez vos FXML manuellement, pensez à vous reporter à la javadoc des classes pour savoir quelles sont les bonnes valeurs à utiliser pour les propriétés des objets et les attributs des balises.
Ceci nous donne le résultat suivant :
Le chemin de l'image est donc défini par le caractère @ sur l'attribut url de la balise Image. Ici l'image se trouvait dans le même package que mon FXML, je n'ai donc pas eu besoin de spécifier un chemin particulier. Si elle avait été placée ailleurs, j'aurais pu tout aussi bien définir un chemin relatif par rapport au package courant ou absolu sur le CLASSPATH ou encore donner une URL web ou l'URI d'un fichier local pour une image externe :
<Image url="@http://www.developpez.com/template/images/logo.png" preserveRatio="true" smooth="true" />
III-F. Utiliser du texte internationalisé▲
Avoir du texte écrit en dur dans le code ou dans le fichier de définition de l'UI ce n'est pas trop mon truc. J'ai l'habitude de créer des applications multilingues et donc il est tout à fait naturel pour moi de mettre mes textes dans des fichiers de ressources externes. Ça tombe bien, le FXML supporte les ressources internationalisées.
Ainsi je peux déclarer le code suivant dans lequel j'ai rajouté une infobulle sur le bouton :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml">
<children>
<Button contentDisplay="GRAPHIC_ONLY" layoutX="14.0" layoutY="14.0" mnemonicParsing="false" text="Button">
<graphic>
<ImageView id="logo" pickOnBounds="true">
<image>
<Image url="@logo.png" preserveRatio="true" smooth="true" />
</image>
</ImageView>
</graphic>
<tooltip>
<Tooltip id="tooltip" text="%visit.developpez.web"/>
</tooltip>
</Button>
</children>
</AnchorPane>
Ici c'est le caractère % qui permet de spécifier qu'on a affaire à une chaine dont la valeur est externalisée.
Si vous cherchez à charger directement le FXML avec le code Java que je vous ai donné précédemment, malheureusement une exception de type javafx.fxml.LoadException avec le message « No resources specified » sera levée lors de l'appel à la méthode load(). En effet, désormais notre FXMLLoader s'attend à recevoir un ResourceBundle en paramètre qui lui permettra de récupérer la traduction appropriée pour la clé visit.developpez.web. Le ResourceBundle est le mécanisme classique qui permet l'internationalisation (I18N) et la localisation (L10N) dans l'API standard Java.
Rajoutons donc dans le package un fichier texte nommé strings.properties qui contient la ligne suivante :
visit.developpez.web=Visitez le site web de développez !
Et modifions le code qui charge le FXML :
2.
3.
4.
5.
6.
7.
8.
// Localisation du fichier FXML.
URL url = getClass().getResource("test5.fxml");
// Chargement du bundle:
ResourceBundle bundle = ResourceBundle.getBundle("test/strings");
// Creation du loader.
FXMLLoader fxmlLoader = new FXMLLoader(url, bundle);
// Chargement du FXML.
AnchorPane root = (AnchorPane) fxmlLoader.load();
Ce qui nous donne, quand on passe le curseur de la souris au-dessus du bouton :
III-G. Nommer des objets▲
Pour le moment, nous nous sommes contentés d'intégrer directement des objets dans le fichier FXML. Cependant, étant donné que nous allons être amenés à les manipuler, il va nous falloir trouver un moyen de référencer ces objets. Et puis nous allons vouloir créer une interface un peu plus complexe par la même occasion. Insérons un nouveau FXML dans notre projet, et nommons-le proxy.fxml. Il contient le code suivant :
Nous avons inclus un GridPane dans notre AnchorPane racine. Ce layout permet de disposer des nœuds suivant une grille de manière assez similaire à une table HTML et vous serez donc probablement amenés à l'utiliser souvent si vous devez créer des formulaires.
Au passage, nous pouvons voir qu'une nouveauté est apparue dans ce nouveau FXML : à plusieurs endroits, nous avons utilisé un nouvel attribut qui sert à définir une identité, fx:id. Cette identité doit être unique pour chaque objet dans un même fichier FXML. D'ailleurs NetBeans soulignera en rouge les duplicata s'il en trouve. Nous avons défini des identités sur la plupart des champs et des contrôles qui récupéreront des valeurs saisies par l'utilisateur. De plus, dans le tout premier RadioButton, nous avons défini un objet de type ToggleGroup et nous lui avons donné une identité avec l'attribut fx:id.
2.
3.
<toggleGroup>
<ToggleGroup fx:id="optionToggleGroup" />
</toggleGroup>
Comme en Swing avec un ButtonGroup, ici en JavaFX, un ToggleGroup permet de regrouper des cases à cocher ou des boutons radio et de s'assurer qu'un seul est sélectionné à la fois. Les autres instances de RadioButton utilisent le même groupe tout en s'y référant grâce au caractère $ et à son identité.
<RadioButton [...] toggleGroup="$optionToggleGroup" [...]
Note : aucune exception ne sera levée si vous vous référez à une identité qui n'existe pas.
Maintenant, rajoutons les chaines de texte suivantes dans notre fichier de ressources, strings.properties :
2.
3.
4.
5.
6.
7.
8.
web.no.proxy=Pas de proxy
web.system.proxy=Utiliser le proxy système
web.manual.proxy=Proxy manuel
web.proxy.host=Hôte
web.proxy.port=Port
web.use.authentication=Utiliser l'authentification ?
web.authenticate.username=Utilisateur
web.authenticate.password=Mot de passe
Si on affiche notre FXML, cela donnera un contenu similaire à :
III-H. Inclure du FXML dans du FXML▲
Il est assez courant de découper une UI en sous-parties ; cela permet de rendre le code qui gère chaque partie, plus lisible et facile à maintenir, tout en offrant la possibilité de réutiliser certaines parties à plusieurs endroits comme dans des assistants, des palettes ou des boites de dialogue. Il est tout à fait possible d'intégrer notre FXML dans un autre FXML :
Nous avons inclus un BorderPane dans notre AnchorPane racine. Les utilisateurs de Swing reconnaîtront dans ce contrôle, un layout qui dispose son contenu de manière similaire au BorderLayout. Notre bouton se trouve dans la partie top, tandis que nous incluons notre FXML proxy.fxml dans la partie bottom ; j'ai également inclus un contrôle WebView dans la partie center. WebView est un composant capable de rendre des pages HTML 5 via WebKit, c'est un équivalent plus moderne du JEditorPane de Swing.
<fx:include source="proxy.fxml" />
La balise fx:include permet d'inclure un fichier FXML dans un autre fichier FXML. Son attribut source permet de définir la localisation du fichier à inclure. Cette valeur peut être un chemin relatif ou absolu par rapport au package courant. Comme n'importe quelle autre entité, il est possible de lui donner une identité avec l'attribut fx:id ce qui se révélera utile par la suite.
L'affichage donnera quelque chose comme ça ; j'en ai profité également pour agrandir un peu la taille de la scène dans le code de mon programme :
III-I. Définir du code dans le FXML▲
Pour le moment, notre interface n'est pas très vivante ; on peut certes cliquer sur quelques boutons et remplir quelques champs texte, mais il ne se passe pas grand-chose… Via le XML nous pouvons également spécifier des callbacks permettant d'appeler des fonctions lorsqu'on interagit avec certains contrôles. Après tout, les callbacks sont des propriétés comme des autres. Vous pouvez même définir le corps de ces méthodes directement dans le fichier FXML.
En théorie, vous pouvez utiliser n'importe quel langage de script qui fonctionne sur la JVM. En pratique, seul l'interpréteur JavaScript (Rhino dans Java 6-7, Nashorn dans Java 8) est présent par défaut, il vous faudra packager tout autre interpréteur avec votre application. Au final, votre degré de réussite dépendra du degré d'implémentation de la JSR223 par votre langage de script ainsi que de sa maturité.
Parmi les changements apportés à ce fichier FXML, le premier est l'ajout de la directive suivante au début du fichier :
<?language javascript?>
Cette directive indique que vos scripts seront exécutés par l'interpréteur JavaScript de la JVM. Si vous utilisez un autre langage de script, vous devrez spécifier ici quel est l'interpréteur à utiliser.
Vous trouverez ensuite, dans la balise racine, un bout de code défini entre des balises fx:script qui contient la définition de la fonction goToDeveloppez().
2.
3.
4.
5.
6.
<fx:script>
function goToDeveloppez() {
java.lang.System.out.println("En avant vers le site de développez !");
browser.getEngine().load("http://www.developpez.com/")
}
</fx:script>
C'est bien du JavaScript, qui appelle l'API Java : la première ligne de la fonction fait une impression sur la console, tandis que la seconde charge la page de garde du site de Développez dans la WebView. Notez au passage que j'ai donné une identité à ma WebView avec l'attribut fx:id et que j'utilise cette identité comme nom de variable dans ma fonction JavaScript.
J'ai, de plus, ajouté l'attribut onAction dans mon bouton en lui passant le nom de la fonction à appeler :
<Button [...] onAction="goToDeveloppez(event);" [...]
Quelques tests simples montrent qu'on aurait tout aussi bien pu écrire le nom de la fonction en omettant le paramètre et le ; final. Les parenthèses sont quant à elles obligatoires :
<Button [...] onAction="goToDeveloppez()" [...]
Lorsque je clique sur le bouton, désormais, la console va afficher :
En avant vers le site de développez !
Et la page de garde du site de Développez s'affiche dans la partie centrale de l'UI. Enfin, si vous n'avez pas besoin de spécifier un proxy sur votre système, bien sûr ! Vous n'alliez pas imaginer que ce contrôle permettant de spécifier un proxy était juste là pour faire joli, tout de même ?
Sinon, pour en revenir à notre fonction JavaScript, vous pouvez normalement utiliser l'intégralité de l'API Java et manipuler tous les composants nommés de votre FXML. Évidemment cela reste du JavaScript interprété au vol au moment de l'exécution, donc il peut être un peu compliqué de trouver les erreurs de syntaxe ou de gérer les exceptions qui seraient levées par le code.
IV. Le contrôleur▲
Même en utilisant du code scripté directement dans le FXML, notre UI est encore bien trop statique, l'ensemble manque sérieusement de flexibilité. Si on s'en tient au modèle MVC (modèle-vue-contrôleur), on aura quand même envie de découpler la vue du contrôleur en externalisant le code qui gère les différents contrôles du formulaire.
IV-A. Spécifier un contrôleur dans le FXML▲
Le format FXML vous permet de spécifier une classe contrôleur via l'attribut fx:controller du nœud racine. Cet attribut doit contenir le nom long (package + nom de classe) de la classe qui va servir de contrôleur à notre FXML.
Évidemment cette classe doit être accessible sur le CLASSPATH au moment de l'exécution, faute de quoi une exception de type javafx.fxml.LoadException, contenant le message « java.lang.ClassNotFoundException: <classe du contrôleur> », sera levée. Si NetBeans ne trouve pas la classe en question, sa déclaration sera soulignée de rouge.
<AnchorPane id="AnchorPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml" fx:controller="test.TestController">
Tout ce que vous avez besoin de faire désormais, c'est de rajouter une nouvelle classe dans votre projet :
2.
3.
4.
5.
package test;
public class TestController {
}
Bravo, vous avez désormais un contrôleur pour votre FXML ! Même s'il ne fait pas grand-chose pour le moment. Vous devrez cependant vous assurer que la classe est bien publique et que son constructeur par défaut (constructeur sans argument) est bien accessible sous peine de lever des exceptions au chargement du FXML.
IV-B. Récupérer une référence sur le contrôleur▲
Vous pouvez récupérer une référence sur le contrôleur de votre FXML une fois que ce dernier a été chargé. Pour cela, il suffit d'appeler la méthode getController() du FXMLLoader et de caster le résultat si besoin. Une nouvelle instance du contrôleur est créée à chaque fois que la méthode load() du FXMLLoader est appelée. Chaque contrôleur est propre à une seule structure chargée en mémoire.
2.
3.
4.
// Chargement du FXML.
AnchorPane root = (AnchorPane) fxmlLoader.load();
// Accès au contrôleur.
TestController controller = (TestController) fxmlLoader.getController();
Une fois une référence sur le contrôleur récupérée, vous pouvez appeler n'importe quelle méthode ou propriété que vous avez définie dessus comme n'importe quel autre objet. Depuis le contrôleur, vous pouvez modifier le contenu de l'arbre graphique du nœud comme bon vous semble : installer/désinstaller des écouteurs, faire du binding sur les propriétés des nœuds, injecter de nouveaux nœuds dans l'arborescence, cacher ou retirer des nœuds existants. Cela ne modifiera pas le contenu du fichier FXML : une fois qu'il a été chargé en mémoire, l'arborescence graphique est totalement découplée du fichier source.
IV-C. Accéder au contenu du FXML▲
Bien sûr, tout cela serait plus intéressant si on pouvait interagir avec le contenu décrit dans le FXML. Il vous est possible de récupérer des références sur tous les objets qui ont reçu des identités dans le FXML via l'annotation @FXML :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
package test;
import javafx.fxml.FXML;
import javafx.scene.control.Button;
import javafx.scene.layout.AnchorPane;
import javafx.scene.web.WebView;
public class TestController {
@FXML
private Button goToWebButton;
@FXML
private WebView browser;
@FXML
private AnchorPane proxyConfiguration;
}
Si vous ajoutez un constructeur dans votre classe, vous verrez que ses membres sont initialement à une valeur null. Les valeurs en provenance du FXML sont injectées durant l'initialisation de la classe après l'appel au constructeur. Si vous essayez de référencer des identités qui ne sont pas dans votre FXML, leur valeur restera null après le chargement. Si vous spécifiez la mauvaise classe pour un membre, une ClassCastException sera levée au chargement.
Pour les classes supportant les Generics, vous pouvez spécifier le type exact même si ce n'était pas possible de le faire dans le FXML. Par exemple, souvenez-vous de notre ComboBox qui contenait des instances de la class Car ; donnons-lui d'abord une identité :
2.
3.
4.
5.
6.
7.
8.
9.
<ComboBox fx:id="carCombo" layoutX="14.0" layoutY="14.0">
<items>
<FXCollections fx:factory="observableArrayList">
<Car brand="Peugeot"/>
<Car brand="Renault"/>
<Car brand="Citroën"/>
</FXCollections>
</items>
</ComboBox>
Il est tout à fait possible d'écrire dans le contrôleur :
2.
@FXML
private ComboBox<Car> carCombo;
Une autre conclusion s'impose : si vous avez deux FXML à la mise en page totalement différente, mais contenant les mêmes identités pour les mêmes types d'objets, il vous est tout à fait possible de conserver la même classe contrôleur pour chacun des deux FXML. En quelque sorte, vous pouvez désormais avoir des contrôles utilisant la même classe contrôleur, mais avec des skins différents.
IV-D. La méthode initialize()▲
Si vous faites que votre contrôleur hérite de l'interface javafx.fxml.Initializable, il est désormais possible d'étendre la méthode initialize() dans le corps de votre classe. Cette méthode prend en paramètre une URL qui est l'emplacement du fichier FXML source qui a été chargé, de même que le ResourceBundle qui est utilisé pour récupérer les textes internationalisés. La méthode initialize() est appelée après que le contenu du FXML a été injecté dans le contrôleur ; donc, sauf erreur de votre part, toutes les références vers vos nœuds et tous les contrôles identifiés auront été correctement initialisées.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
package test;
import java.net.URL;
import java.util.ResourceBundle;
import javafx.fxml.FXML;
import javafx.fxml.Initializable;
import javafx.scene.control.Button;
import javafx.scene.layout.AnchorPane;
import javafx.scene.web.WebView;
public class TestController implements Initializable {
@FXML
private Button goToWebButton;
@FXML
private WebView browser;
@FXML
private AnchorPane proxyConfiguration;
@Override
public void initialize(URL url, ResourceBundle rb) {
// Tapez votre code ici.
}
}
Vous pouvez utiliser cette méthode pour vérifier que vos références ont toutes été correctement chargées (par exemple, via des tests assert), mettre des valeurs par défaut dans vos contrôles, faire du binding ou encore installer les écouteurs de base avant que le contrôle ne soit attaché au reste de votre UI et ne puisse être manipulé par la classe appelante. Conserver une référence sur le ResourceBundle permet également de continuer à utiliser des ressources internationalisées lorsqu'on change le texte dans l'interface ultérieurement.
IV-E. Accéder au sous-contrôleur▲
Chouette, nous pouvons définir des contrôleurs pour chacun de nos FXML ! Cependant ce n'est pas très pratique dans le cas de FXML inclus dans d'autres FXML puisque nous ne contrôlons pas le chargement et donc que nous ne pouvons pas récupérer de références sur le sous-contrôleur.
Reprenons notre exemple d'inclusion de FXML dans un autre FXML. Tout ce que nous avons à faire c'est de modifier la description de la balise racine pour pointer sur une classe contrôleur. C'est exactement ce que nous avons fait à la section précédente :
<AnchorPane id="AnchorPane" prefHeight="-1.0" prefWidth="-1.0" xmlns:fx="http://javafx.com/fxml" fx:controller="test.ProxyController">
Et inclure la classe test.ProxyController dans notre projet. Encore une fois, pareil que précédemment. Je vais juste rajouter un peu de code dans la méthode initialize() de manière à ce que notre UI commence un peu à se comporter normalement : faire en sorte que les contrôles et champs soient désactivés quand on n'est pas censé pouvoir les utiliser.
Souvenez-vous, dans notre FXML principal, nous avions assigné l'identité proxyConfiguration au FXML secondaire proxy.fxml que nous avons inclus :
<fx:include fx:id="proxyConfiguration" source="proxy.fxml" />
En fait, nous avons déjà implicitement accès au contrôleur de proxy.fxml depuis le contrôleur de notre FXML principal. Pour rendre cet accès explicite, il suffit pour cela de déclarer :
2.
3.
4.
@FXML
private AnchorPane proxyConfiguration;
@FXML
private ProxyController proxyConfigurationController;
La convention est simple :
@FXML
private <type du contrôleur du FXML> <identité du FXML>Controller ;
Et c'est tout ! Nous pouvons désormais accéder au sous-contrôleur et manipuler ses méthodes et propriétés exactement comme avec n'importe quel autre objet Java.
IV-F. Appeler des méthodes du contrôleur depuis le FXML▲
Reprenons le code de notre bouton, précédemment nous avions ajouté un callback qui appelait une fonction écrite en JavaScript dans le corps même du FXML. Nous allons supprimer notre code JavaScript et modifier ce callback pour appeler une méthode qui se trouve maintenant dans le contrôleur :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
<Button fx:id="goToWebButton" contentDisplay="GRAPHIC_ONLY" mnemonicParsing="false" onAction="#goToDeveloppez" text="Button">
<graphic>
<ImageView id="logo" pickOnBounds="true">
<image>
<Image url="@logo.png" preserveRatio="true" smooth="true" />
</image>
</ImageView>
</graphic>
<tooltip>
<Tooltip id="tooltip" text="%visit.developpez.web" />
</tooltip>
</Button>
Ici, le caractère # permet de spécifier le nom d'une fonction du contrôleur qui sera associée au callback onAction de notre bouton. À l'exécution, lorsqu'on clique sur le bouton, une fonction portant ce nom sera recherchée et, si elle est découverte, elle sera appelée. Pour le moment cette fonction n'existe pas encore, le nom de la fonction sera même souligné en rouge dans NetBeans puisqu'il n'arrive pas à la trouver.
Nous devons rajouter le code suivant dans notre contrôleur principal :
2.
3.
4.
5.
@FXML
private void goToDeveloppez(ActionEvent event) {
System.out.println("Méthode du contrôleur");
browser.getEngine().load("http://www.developpez.com/");
}
Désormais c'est cette méthode qui sera appelée lorsque l'utilisateur clique sur le bouton. Si la fonction n'est pas définie dans le contrôleur lors du chargement du FXML, une exception de type LoadException incluant le message « Controller method "goToDeveloppez" not found » sera levée.
V. SceneBuilder▲
Comme vous devez vous en douter, je n'ai, en fait, pratiquement pas tapé une ligne de code FXML dans la plupart des exemples précédents que je vous ai donnés. Tout d'abord, le support du FXML s'améliore dans NetBeans à chaque nouvelle version, ce qui fait que NetBeans 7.3 et les versions ultérieures supportent par exemple la complétion automatique des valeurs et est capable de suggérer les noms des attributs/propriétés à utiliser dans la majorité des cas. J'imagine qu'Eclipse et IntelliJ IDEA ne doivent pas être en reste non plus.
De plus, Oracle a développé en interne et a rendu public gratuitement un outil de conception graphique nommé SceneBuilder. Cet outil permet une édition visuelle du contenu du FXML, pour tout ce qui est des classes graphiques (les classes non graphiques demandant toujours une édition manuelle). La version 1.0 a été rendue disponible pour Windows et MacOS en septembre 2012, suivie de la version 1.1 pour Windows, MacOS et Linux en septembre 2013. La 2.0, a quant à elle, été publiée en mai 2014 et qui offre un support des contrôles de JavaFX 8 (disponible dans le JDK8).
Cette dernière version est passée en open source dans le cadre de l'OpenJFX et son code source est disponible sur le Mercurial du projet (sur le chemin rt/apps/scenebuilder). Le projet continue d'être maintenu pour ajouter des fonctionnalités suivant les évolutions de JavaFX ou pour corriger des bogues. Il est possible de signaler des bogues sur le Java Bug Database d'Oracle et le Java Bug System de l'OpenJDK.
À partir du JDK 8_40, Oracle a cessé de distribuer des binaires précompilés de SceneBuilder. Vous pouvez donc :
- soit télécharger les sources de l'OpenJFX et tenter de recompiler l'application ;
- soit récupérer un fichier JAR ou des installeurs natifs contenant une version précompilée du logiciel, par exemple sur le site de la compagnie Gluon (dans la section Products → Downloads - leur version de SceneBuilder reste un outil gratuit). La version de SceneBuilder disponible chez Gluon, nommée SceneBuilder 8.0.0, a été mise à jour pour supporter les nouveautés du JDK 8_40.
Les anciennes versions de SceneBuilder sont toujours disponibles chez Oracle, dans la page des archives accessibles depuis la page produit du logiciel.
Résumons :
- SceneBuilder 1.0 ou 1.1 : publié par Oracle et destiné à JavaFX 2.x ;
- SceneBuilder 2.0 : publié par Oracle et destiné à JavaFX 2.2 ou JavaFX 8.0 ;
- SceneBuilder 8.0.0 : publié par Gluon et destiné à JavaFX 8.0_40.
V-A. Lancement▲
S'il est correctement installé, SceneBuilder sera automatiquement lancé par NetBeans lorsque vous double-cliquez sur un fichier FXML dans l'arborescence du projet. Il est possible de configurer le chemin d'accès vers le logiciel, en allant, dans NetBeans dans Tools → Options puis en choisissant la catégorie Java et l'onglet JavaFX.
Note : actuellement cela ne fonctionne pas avec la version de SceneBuilder fournie par Gluon. La compagnie a confirmé que ceci est dû à un bogue de NetBeans. Il faudra patienter le temps que l'équipe de développement de l'IDE corrige ce souci pour avoir de nouveau accès à l'intégration de SceneBuilder dans NetBeans.
Astuce : si SceneBuilder est activé, pour éditer un FXML directement dans l'éditeur de code de NetBeans plutôt que dans SceneBuilder, il faut cliquer avec le bouton de droite sur le FXML et choisir Edit au lieu de Open.
V-B. Présentation rapide▲
Par défaut SceneBuilder 1.0 ou 1.1 s'ouvre sur une page simple contenant un simple AnchorPane en nœud racine. En fait, il s'agit exactement du même contenu que le tout premier FXML que je vous ai montré au début de cet article.
SceneBuilder 2.0 (ou ultérieur) s'ouvre, quant à lui, sur un document vierge et vous laisse le loisir de placer vous-même l'élément racine de votre FXML. N'importe quel conteneur peut faire l'affaire, mais je vous conseille en général d'utiliser un AnchorPane qui suffit largement pour la plupart des usages.
Le fonctionnement est similaire à ce que vous pouvez trouver dans la plupart des éditeurs d'interfaces graphiques.
- L'espace de travail au centre permet de sélectionner des nœuds et de les déplacer ou de les redimensionner à la souris.
- La partie Library en haut à gauche contient la liste des nœuds graphiques les plus courants dans l'API. Vous pouvez faire du drag'n drop de nœud depuis la Library vers la Hierarchy ou vers l'espace de travail.
- La partie Hierarchy en bas à gauche vous montre l'arborescence graphique qui correspond au contenu de votre FXML.
- La partie Inspector sur la droite vous montre les différentes propriétés et options que vous pouvez configurer sur le nœud actuellement sélectionné (par défaut la racine du document). Les propriétés sont réparties en trois grandes catégories :
- les Properties, qui sont les propriétés générales du nœud ;
- le Layout, des propriétés liées au positionnement dans la scène et le contrôle parent ;
- le Code permet de donner le nom des méthodes utilisées par les callbacks. Dans SceneBuilder 1.x, il est aussi possible d'y spécifier le nom long la classe du contrôleur (uniquement sur le nœud racine).
- La partie Controller (SceneBuilder 2.0 ou ultérieur) tout en bas à gauche sous la partie Hierarchy. Permet de spécifier le nom long la classe du contrôleur (uniquement sur le nœud racine).
V-C. Aperçu de l'internationalisation▲
Lorsque vous chargez une UI contenant du texte internationalisé dans SceneBuilder, par défaut, il ne vous affichera que les clés de traduction.
Vous pouvez avoir un aperçu des valeurs traduites dans votre interface en allant dans le menu Preview → Internationalisation → Set Resources… et en choisissant le fichier de propriétés contenant les traductions de votre UI.
Dans SceneBuilder 1.0 ou 1.1, cela aura pour effet d'insérer une ligne supplémentaire dans votre XML de la forme :
<?scenebuilder-preview-i18n-resource strings.properties?>
Cette directive contient le chemin relatif vers le fichier properties utilisé pour l'internationalisation. Elle n'a pas d'usage en dehors de SceneBuilder 1.0 et 1.1.
SceneBuilder 2.0 utilise un mécanisme différent pour stocker ce genre de valeurs (dans ses propriétés utilisateur) et ne rajoute aucune ligne dans le fichier FXML.
Dans tous les cas, le programmeur devra quand même manuellement attacher un ResourceBundle à son FXMLLoader dans son code, comme montré précédemment, car cette fonctionnalité ne sert qu'à avoir un aperçu de la traduction dans SceneBuilder.
V-D. Aperçu du style▲
Les contrôles et nœuds de JavaFX supportent les Cascading Syle Sheets (CSS). Lorsque vous chargez une UI dans SceneBuilder, elle s'affichera avec le style par défaut et le style qui est décrit de manière inline dans le FXML (dans l'attribut style de chaque balise décrivant un nœud). Si vous avez une feuille de style redéfinissant les styles par défaut des nœuds ou définissant vos propres styles (voir attribut styleClass des nœuds), SceneBuilder peut l'utiliser.
Pour cela, allez dans le menu Preview → Scene Style Sheets → Add a Style Sheet… et choisissez un ou plusieurs fichiers CSS.
Dans SceneBuilder 1.0 ou 1.1, cela aura pour effet d'insérer une ou plusieurs lignes supplémentaires dans votre XML de la forme :
<?scenebuilder-stylesheet test.css?>
Cette directive contient le chemin relatif vers le fichier css utilisé pour le style. Elle n'a pas d'usage en dehors de SceneBuilder 1.0 et 1.1 et les feuilles de style définies ne seront pas appliquées au chargement du fichier.
Ici aussi, SceneBuilder 2.0 stocke ses valeurs différemment (via ses préférences utilisateur) sans rajouter de ligne dans le fichier FXML.
Comme pour l'internationalisation, il s'agit uniquement d'un aperçu pour l'édition dans SceneBuilder. Une fois chargé dans son application, le fichier FXML sera soumis aux feuilles de style attachées à la scène ou sur ses contrôles parents.
Il est cependant possible de spécifier des feuilles de style indépendamment pour chaque nœud en utilisant le champ Stylesheets de la partie Inspector ce qui aura pour effet d'insérer un attribut styleSheet dans le nœud XML concerné dans le fichier FXML. Ces feuilles de style là font partie intégrante du FXML et seront bien appliquées au chargement du fichier.
V-E. CSS analyzer▲
Il peut-être parfois assez prise de tête de comprendre quel est le style qui est en train de s'appliquer à tel ou tel attribut ou sous-partie d'un nœud. À partir de SceneBuilder 1.1, nous avons accès à un nouvel outil connu sous le nom de CSS Analyzer. Il est accessible via le menu View → Show CSS Analyzer.
Un nouveau panneau s'affichera en bas de l'UI qui permet d'explorer l'origine de la valeur d'un attribut graphique avec, par ordre de priorité : Defaults < Inspector < Stylesheets < Inline Styles.
- Defaults - il s'agit des valeurs provenant du style par défaut (Caspian dans JavaFX 2.x, Modena dans JavaFX 8.x).
- Inspector - les valeurs settées via la partie Inspector de SceneBuilder qui se traduisent généralement par des attributs de la balise du nœud dans le FXML.
- StyleSheets - les valeurs définies dans la ou les feuilles de styles utilisées en aperçu ainsi que celles placées sur chacun des nœuds. L'ordre des styles dépend de leur ordre d'écriture dans les fichiers et de l'ordre d'ajout des feuilles de style. Ils sont également impactés par les styles définis dans le champ styleClass de la partie Inspector.
- Inline Styles - les styles définis dans le champ style de la partie Inspector, qui sont sauvegardés dans l'attribut styleClass de la balise du nœud dans le FXML.
V-F. Contrôles customisés▲
Dans sa version 1.1, SceneBuilder ne supporte pas très bien l'édition de FXML contenant des contrôles et classes customisées ou provenant de bibliothèques externes. Cela fonctionne de manière un peu plus transparente dans la version 2.0, sans toutefois être parfait.
Lorsqu'une classe customisée est utilisée dans le FXML, s'il s'agit de nœuds graphiques, vous devriez pouvoir avoir accès à leurs propriétés du moins pour celles utilisant des types Java classiques ; mais dans le meilleur des cas, le plus souvent, si votre rendu est dépendant de valeurs qui ne sont settées que lors de l'exécution, l'affichage de votre nœud se limitera à un rectangle gris. Dans le pire des cas, le FXML ne se chargera pas.
V-F-1. Dans SceneBuilder 1.1▲
Si vous utilisez des classes non supportées dans la version 1.1, SceneBuilder fera apparaitre au démarrage une boite de dialogue vous demandant de rajouter les versions compilées de ces classes sur son CLASSPATH. Voici par exemple ce que j'obtiens quand j'essaie d'ouvrir le FXML dans lequel je manipulais des instances de la classe test.Car avec SceneBuilder 1.1 :
Vous devrez donc rajouter manuellement le chemin vers un endroit où des JAR ou des fichiers .class sont disponibles (ici le répertoire racine de compilation du projet NetBeans dans lequel se trouvent le package test et ses classes compilées) :
Et ensuite, cliquer sur le bouton Apply de manière à voir apparaitre « Unknown types resolved » :
Vous pouvez enfin cliquer sur le bouton Close.
V-F-2. Dans SceneBuilder 2.0▲
Le support des contrôles customisés est un peu plus fonctionnel dans SceneBuilder 2.0. à l'ouverture du fichier FXML, le contrôle sera marqué comme étant inconnu et n'aura pas de taille.
Il est possible de résoudre ce problème en allant dans le menu de configuration de l'onglet Library et de choisir la commande Import JAR/FXML File… Cela aura pour effet d'afficher une boite de dialogue qui permettra de sélectionner le fichier JAR contenant le contrôle à importer.
Le logiciel explorera alors le contenu du fichier sélectionné pour afficher les nœuds graphiques qu'il contient de manière à ce que vous puissiez les utiliser.
Lorsque votre sélection est terminée, cliquez sur Import Component et votre contrôle apparaitra alors dans une nouvelle catégorie Custom dans l'onglet Library.
Quelques-unes de ses propriétés sont visibles dans l'onglet Inspector ; elles restent cependant accessibles uniquement en lecture seule. Certaines propriétés restent invisibles cependant sans qu'on en sache la raison réelle.
Pour supprimer un contrôle customisé de SceneBuilder, il faut naviguer jusqu'au répertoire dans lequel le logiciel a recopié le fichier JAR contenant le contrôle et supprimer ce fichier. Cela peut être fait en allant dans le menu de configuration de l'onglet Library et en choisissant la commande nommée Reveal in Explorer (sous Windows, l'intitulé de la commande variera en fonction de votre système d'exploitation).
Cela ouvrira votre explorateur de fichiers dans le répertoire utilisé par le logiciel pour stocker ses fichiers utilisateur. Fermez alors SceneBuilder et, dans votre navigateur de fichiers, déplacez-vous dans le sous-répertoire Library, vous devriez alors être en mesure de supprimer le fichier JAR incriminé avant de relancer SceneBuilder.
VI. Code final▲
Il est temps de voir la version finale du programme. J'ai rajouté deux classes pour prendre en charge les redéfinitions du proxy et un peu de code pour ajouter du binding et quelques écouteurs dans la méthode initialize() du contrôleur secondaire. De plus, cette dernière classe expose désormais quelques propriétés et dispose d'une méthode qui modifie le proxy de la JVM.
VI-A. Main.java▲
Programme principal :
VI-B. string.properties▲
Fichier de ressources, contient les traductions des textes de l'UI :
VI-C. test10.fxml▲
FXML principal :
VI-D. TestController.java ▲
Contrôleur principal, demande la reconfiguration du proxy avant d'accéder au site web :
VI-E. proxy.fxml ▲
FXML secondaire :
VI-F. ProxyController.java ▲
Contrôleur secondaire, se charge également de réinitialiser le proxy. Certaines valeurs sont accessibles publiquement par des propriétés en lecture seule ce qui permet de les observer pour les stocker dans des préférences pour plus tard. Le mot de passe de connexion reste interne à la classe.
VI-G. ProxyType.java▲
Classe annexe, permet de définir les différents types de configuration du proxy :
2.
3.
4.
5.
package test;
public enum ProxyType {
NONE, SYSTEM, MANUAL;
}
VI-H. CustomProxySelector.java ▲
Classe annexe, servira de sélectionneur de proxy dans le cas où l'utilisateur décide d'utiliser un proxy manuel :
VII. Conclusion▲
Voilà, vous avez désormais réalisé une première UI JavaFX à base de FXML ; vous savez comment modifier les propriétés des nœuds, inclure un FXML dans un autre FXML ou encore comment écrire un contrôleur pour réagir aux actions de l'utilisateur. Il reste encore d'autres fonctionnalités intéressantes dans FXML comme le fait de pouvoir injecter le nœud racine du document ou le contrôleur dans le chargeur et je vous invite à consulter la FAQ JavaFX de Développez pour en savoir plus.
VIII. Remerciements▲
Je tiens à remercier toute l'équipe du forum Développez ainsi que Mickael Baron et Logan Mauzaize pour leurs suggestions et leur relecture du présent article. Je tiens également à remercier Claude Leloup pour ses corrections orthographiques.