Document mis à jour le 21 avril 2001.
Je suis ouvert à n'importe qu'elle suggestion qui pourrait m'aider à améliorer
ces matériaux. N'hésitez pas d'écrire à l'auteur, Jonathan
Revusky.
Vous vous souviendrez que, dans le premier exemple, notre méthode execDefault()
a exposé deux variables de page. Les deux variables étaient
des chaînes simples -- ou bien on pourrait dire des scalaires. Tout en
étant une grande avance, si on compare avec les pages HTML complètement
statiques, ça ne représente qu'une partie infime de ce qu'on peut faire avec des
pages modèles. Comme nous verrons, ce système nous permet d'exposer de
façon dynamique des structures de données arbitairement complèxes, composées de listes
et de correspondances -- en plus de scalaires.
Cette application contient 3 pages modèles. La page default.nhtml
montre toutes les entrées du système. La page add.nhtml
inclut un
formulaire qui permit à l'usager de mettre une entrée dans le système. La page thanks.nhtml
remercie simplemente à l'usager de ses commentaires, après avoir traité le
formulaire. Jetez un coup d'oeil à default.nhtml
. Comme nous avons
déjà indiqué dans le premier exemple, la librairie Freemarker se sert d'une
syntaxe de ${...} pour indiquer le contenu dynamique, c'est à dire les variables
de page.
La page default.nhtml
introduit un autre élement de la syntaxe de
Freemarker. Regardez la ligne:
<list entries as entry>
Cela suppose qu'il existe une variable du genre list qui s'appelle entries
.
Une variable du type scalaire, en étant une chaîne, est exposée
normalmente avec cette syntaxe ${...}. Mais à différence, ce qu'on a à faire
avec une variable du type list telle que entries
dans ce
cas-ci, c'est qu'il faut itérer a travers ses éléments. C'est
précisément cela que l'instruction <list entries as entry>
dit en effet. Le code à l'intérieur de ce bloc list
se repète n
fois, où n, c'est le nombre d'éléments de la liste. La variable entry à
l'intérieur du bloc représente la subvariable de la liste à travers laquelle on
est en train d'itérer.
Ce qui rend cet exemple encore plus intéressant, c'est que les éléments de la
liste entries
soient à la fois des correspondances, avec
leurs propres subvariables. Ce sont ces subvariables-là qui sont finalement des
scalaires. Donc, les subvariables de entry
sont montrées
directement sur la page avec la syntaxe ${...} -- c'est à dire, ${entry.name}
etcetera.
Maintenant que vous avez jeté un coup d'oeil à la page modèle qui montre les entrées, regardez maintenant le code java dans GuestbookServletInteraction.java. Remarquez jusqu'à quel point le méthode execDefault() est bref.
public void execDefault() throws IOException { this.page = getPage("default.nhtml"); page.expose("entries", entries); // expose la liste d'entrées à la page }
A vrai dire, le code java de ce servlet est extraordinairement bref. Le méthode
plus compliqué, c'est execProcess() qui traite les variables CGI qui sont envoyées
par le formulaire da la pageadd.nhtml
. Si l'usager ne remplit pas
le champ "name", le méthode expose une variable qui sert de
message d'erreur. Si l'usager a bien rempli le formulaire, on crée un hashtable
qui contient les subvariables qui composent l'entrée du guestbook et on l'additionne
à la liste statique d'entrées.
Remarquez bien que le méthode exposeDefaultVariables
nous fournit
un endroit où on peut mettre des variables qui seront toujours exposées,
independamment du méthode execXXX qui a été invoqué.
Tout en étant primitif, vu que cet exemple laisse à côté pour le moment la persistance des données, il réussit à faire pas mal de choses avec peu de code. Cela est dû en grande partie à la possibilité d'exposer une structure de données arbitrairement complèxe à la page d'un seul coup. En ce cas-ci on a pu mettre une liste -- qui à la fois contenait des variables qui étaient des correspondances -- dans la page, et ensuite montrer tout le contenu incrusté dans la page finale, sans à peine écrire du code java pour toute cette opération assez complèxe. Remarquez aussi qu'on peut incruster des listes et des correspondances jusqu'à un niveau arbitraire de complexité! On pourrait avoir des listes de listes qui enfin contiennent des correspondances qui contiennent encore des listes!
Etant donné que tout le code -- si on compte le côté java et les pages modèles -- arrive à plus au moins cent lignes, il devrait être assez faisable d'étudier cet exemple et comprendre bien tous les éléments qui le composent.
Je vous encourage à effectuer des petits changements au code de l'exemple (côté java et les pages) pour observer leur effet. Cela peut renforcer ce que vous avez appris. Quand vous aurez bien assimilé cet exemple, vous devriez passer au prochain exemple, le mini-rolodex.