Modifions notre exemple afin d'y inclure la gestion d'un paramètre nommé auteur : Code : Java - Servlet
response ) throws ServletException, IOException{
String paramAuteur = request.getParameter( "auteur" );
String message = "Transmission de variables : OK ! " + paramAuteur; request.setAttribute( "test", message );
this.getServletContext().getRequestDispatcher( "/WEB-INF/test.jsp" ).forward( request, response );
}
La seule ligne nécessaire pour cela est la ligne 2 : il suffit de faire appel à la méthode getParameter() de l'objet requête, en lui passant comme argument le nom du paramètre que l'on souhaite récupérer. La méthode retournant directement le contenu du paramètre, je l'ai ici inséré dans une String que j'ai nommée paramAuteur.
Pour vous montrer que notre servlet récupère bien les données envoyées par le client, j'ai ajouté le contenu de cette String au message que je transmets ensuite à la JSP pour affichage. Si vous appelez à nouveau votre servlet depuis votre navigateur, rien ne va changer. Mais si cette fois vous l'appelez en ajoutant un paramètre nommé auteur à l'URL, par exemple :
Code : URL
http://localhost:8080/test/toto?auteur=Coyote
Alors vous observerez que le message affiché dans le navigateur contient bien la valeur du paramètre précisé dans l'URL : Code : HTML - Contenu de la page finale
<!DOCTYPE html>
<html> <head>
<meta charset="utf-8" /> <title>Test</title> </head>
<body>
<p>Ceci est une page générée depuis une JSP.</p> <p>
Transmission de variables : OK ! Coyote </p>
</body> </html>
Vous avez donc ici la preuve que votre paramètre à bien été récupéré par la servlet. Comprenez également que lorsque vous envoyez un paramètre, il reste présent dans la requête HTTP durant tout son cheminement. Par exemple, nous pouvons très bien y accéder depuis notre page JSP sans passer par la servlet, de la manière suivante :
Code : JSP - /WEB-INF/test.jsp
<!DOCTYPE html>
<html> <head>
<meta charset="utf-8" /> <title>Test</title> </head>
<body>
<p>Ceci est une page générée depuis une JSP.</p> <p>
<%
String attribut = (String) request.getAttribute("test"); out.println( attribut );
String parametre = request.getParameter( "auteur" ); out.println( parametre );
%> </p>
</body> </html>
En procédant ainsi, lorsque nous appelons l'URL en y précisant un paramètre nommé auteur, nous obtenons bien le résultat escompté : notre JSP affiche une seconde fois "Coyote", cette fois en récupérant directement la valeur du paramètre depuis la requête HTTP.
Si vous ne précisez pas de paramètre auteur dans l'URL, alors la méthode getParameter() renverra null en lieu et place du contenu attendu.
Note : il est très imprudent de procéder à l'utilisation ou à l'affichage d'un paramètre transmis par le client sans en
contrôler et éventuellement sécuriser son contenu auparavant. Ici il s'agit d'un simple exemple, nous ne nous préoccupons pas encore des problèmes potentiels. Mais c'est une bonne pratique de toujours contrôler ce qu'on affiche au client. Nous y reviendrons à plusieurs reprises dans la suite du cours dans des cas plus concrets, et vous comprendrez alors mieux de quoi il retourne.
Nous allons nous arrêter là pour le moment. L'utilisation la plus courante des paramètres dans une application web est la récupération de données envoyées par le client via des formulaires, mais nous ne sommes pas encore prêts pour cela. Avant de passer à la suite, une dernière petite précision s'impose.
Quelle est la différence entre ces paramètres et les attributs que nous avons découverts en début de chapitre ? Il ne faut pas faire de confusion ici :
les paramètres de requête sont un concept appartenant au protocole HTTP. Ils sont envoyés par le client au serveur directement au sein de l'URL, et donc sous forme de chaînes de caractères. Il n'est pas possible de forger des paramètres dans l'objet HttpServletRequest, il est uniquement possible d'y accéder en lecture. Ce concept n'étant absolument pas spécifique à la plate-forme Java EE mais commun à toutes les technologies web, il ne peut pas être "objectifié". C'est la raison pour laquelle la méthode getParameter() retourne quoi qu'il arrive un objet de type String, et il n'est pas possible d'ajouter une quelconque logique supplémentaire à un tel objet.
les attributs de requête sont un concept appartenant au conteneur Java, et sont donc créés côté serveur : c'est au sein du code de l'application que l'on procède à leur initialisation, et qu'on les insère dans la version "objectifiée" de la requête, à savoir l'objet HttpServletRequest. Contrairement aux paramètres, ils ne sont pas présents directement dans la requête HTTP mais uniquement dans l'objet Java qui l'enveloppe, et peuvent contenir n'importe quel type de données. Ils sont utilisés pour permettre à une servlet de communiquer avec d'autres servlets ou pages JSP.
En résumé, les paramètres de requête sont propres au protocole HTTP et font partie intégrante de l'URL d'une requête, alors que les attributs sont des objets purement Java créés et gérés par le biais du conteneur.
En résumé
Un attribut de requête est en réalité un objet stocké dans l'objet HttpServletRequest, et peut contenir n'importe quel type de données.
Les attributs de requête sont utilisés pour permettre à une servlet de transmettre des données à d'autres servlets ou à des pages JSP.
Un paramètre de requête est une chaîne de caractères placée par le client à la fin de l'URL de la requête HTTP. Les paramètres de requête sont utilisés pour permettre à un client de transmettre des données au serveur.
Prochaine étape : l'apprentissage de la technologie JSP. Les prochains chapitres y sont entièrement consacrés, avec au programme la découverte de la syntaxe, des balises, etc. Bref, tout le nécessaire pour créer des vues dynamiques sans avoir à écrire de Java (ou presque) !
Le JavaBean
Ce court chapitre a pour unique objectif de vous présenter un type d'objet un peu particulier : le JavaBean. Souvent raccourci en "bean", un JavaBean désigne tout simplement un composant réutilisable. Il est construit selon certains standards, définis dans les spécifications de la plate-forme et du langage Java eux-mêmes : un bean n'a donc rien de spécifique au Java EE.
Autrement dit, aucun concept nouveau n'intervient dans la création d'un bean : si vous connaissez les bases du langage Java, vous êtes déjà capables de comprendre et de créer un bean sans problème particulier. Son utilisation ne requiert aucune bibliothèque ; de même, il n’existe pas de superclasse définissant ce qu'est un bean, ni d'API.
Ainsi, tout objet conforme à ces quelques règles peut être appelé un bean. Découvrons pour commencer quels sont les objectifs d'un bean, puis quels sont ces standards d'écriture dont je viens de vous parler. Enfin, découvrons comment l'utiliser dans un projet !