| Penser en Java 2nde édition | - | Sommaire | Préface | Avant-propos | Chapitre : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Annexe : A B C D | Tables des matières | - | Thinking in Java |
À partir de là, et tant que le code source JSP de la page n'est pas modifié, tout se passe comme si on avait une page HTML statique associée à des servlets (en réalité, le code HTML est généré par la servlet). Si on modifie le code source de la JSP, il est automatiquement recompilé et rechargé dès que cette page sera redemandée. Bien entendu, à cause de ce dynamisme le temps de réponse sera long lors du premier accès à une JSP. Toutefois, étant donné qu'une JSP est généralement plus utilisée qu'elle n'est modifiée, on ne sera pas généralement affecté par ce délai.
La structure d'une page JSP est à mi-chemin d'une servlet et d'une page HTML. Les tags JSP commencent et finissent comme les tags HTML, sauf qu'ils utilisent également le caractère pourcent (%), ainsi tous les tags JSP ont cette structure :
Le premier caractère pourcent doit être suivi d'un autre caractères qui définit précisément le type du code JSP du tag.
Voici un un exemple extrêmement simple de JSP utilisant un appel standard à une bibliothèque Java pour récupérer l'heure courante en millisecondes, et diviser le résultat par 1000 pour produire l'heure en secondes. Une expression JSP (<%= ) est utilisée, puis le résultat du calcul est mis dans une String et intégré à la page Web générée :
Dans les exemples JSP de ce livre, la première et la dernière ligne ne font pas partie du fichier code réel qui est extrait et placé dans l'arborescence du code source de ce livre.
Lorsque le client demande une page JSP, le serveur Web doit avoir été configuré pour relayer la demande vers le conteneur JSP, qui à son tour appelle la page. Comme on l'a déjà dit plus haut, lors du premier appel de la page, les composants spécifiés par la page sont générés et compilés par le conteneur JSP en tant qu'une ou plusieurs servlets. Dans les exemples ci-dessus, la servlet doit contenir le code destiné à configurer l'objet HttpServletResponse, produire un objet PrintWriter (toujours nommé out), et enfin transformer le résultat du calcul en un objet String qui sera envoyé vers out. Ainsi qu'on peut le voir, tout ceci est réalisé au travers d'une instruction très succincte, mais en moyenne les programmeurs HTML/concepteurs de site Web ne seront pas qualifiés pour écrire un tel code.
Les servlets comportent des classes fournissant des utilitaires pratiques, comme HttpServletRequest, HttpServletResponse, Session, etc. Les objets de ces classes font partie de la spécification JSP et sont automatiquement disponibles pour vos JSP sans avoir à écrire une ligne de code supplémentaire. Les objets implicites d'une JSP sont décrits dans le tableau ci-dessous.
| Variable implicite | "text-decoration: none">Du Type (javax.servlet) | Description | Visibilité |
| demande (request) | Sous-type de HttpServletRequest dépendant du protocole | La demande qui déclenche l'appel du service. | demande |
| réponse | Sous-type de HttpServletResponse dépendant du protocole | La réponse à la demande. | page |
| pageContext | jsp.PageContext | Le contexte de page encapsule les choses qui dépendent de l'implémentation et fournissent des méthodes commodes ainsi que l'accès à un espace de nommage pour ce JSP. | page |
| session | Sous-type de http.HttpSession dépendant du protocole | L'objet session créé pour le client demandeur. Voir l'objet Session pour les servlets. | session |
| application | ServletContext | Le contexte de servlet obtenu depuis l'objet configuration de servlet (e.g., getServletConfig(), getContext( ). | app |
| out | jsp.JspWriter | L'objet qui écrit dans le flux sortant. | page |
| config | ServletConfig | Le ServletConfig pour ce JSP. | page |
| page | java.lang.Object | L'instance de cette classe d'implémentation de page.s gérant la demande courante. | page |
La visibilité de chaque objet est extrêmement variable. Par exemple, l'objet session a une visibilité qui dépasse la page, car il englobe plusieurs demandes client et plusieurs pages. L'objet application peut fournir des services à un groupe de pages JSP représentant une application Web.
Les directives sont des messages adressés au conteneur de JSP et sont reconnaissables au caractère » @] :
Les directives n'envoient rien sur le flux out, mais sont importantes lorsqu'on définit les attributs et les dépendances de pages avec le conteneur JSP. Par exemple, la ligne :
exprime le fait que le langage de scripting utilisé dans la page JSP est Java. En fait, la spécification JSP décrit seulement "font-style: normal">la sémantique des scripts pour un atttribut de langage égal à [Java. « La raison d'être de cette directive est d'introduire la flexibilité dans la technologie JSP. Dans le futur, si vous aviez à choisir un autre langage, par exemple Python (un bon choix de langage de sripting), alors ce langage devra supporter le Java Run-time Environment en exposant la technologie du modèle objet Java à l'environnement de scripting, en particulier les variables implicites définies plus haut, les propriétés JavaBeans, et les méthodes publiques.
La directive la plus importante est la directive de page. Elle définit un certain nombre d'attributs dépendant de la page et les communique au conteneur JSP. Parmi ces attributs : language, extends, import, session, buffer, autoFlush, isThreadSafe, info et errorPage. Par exemple :
Cette ligne indique tout d'abord que la page nécessite une participation à une session HTTP. Puisque nous n'avons pas décrit de directive de langage le conteneur JSP utilisera Java par défaut et la variable de langage de scripting implicite appelée session sera du type javax.servlet.http.HttpSession. Si la directive avait été false alors la variable implicite session n'aurait pas été disponible. Si la variable session n'est pas spécifiée, sa valeur par défaut est » true.]
L'attribut import décrit les types disponibles pour l'environnement de scripting. Cet attribut est utilisé tout comme il le serait dans le langage de programmation Java, c'est à dire une liste d'expressions import ordinaires séparées par des virgules. Cette liste est importée par l'implémentation de la page JSP traduite et reste disponible pour l'environnement de scripting. À nouveau, ceci est actuellement défini uniquement lorsque la valeur de la directive de langage est » java.]
Une fois l'environnement de scripting mis en place au moyen des directives on peut utiliser les éléments du langage de scripting. JSP 1.1 possède trois éléments de langage de scripting declaration, scriptlet, et expression. Une déclaration déclare des éléments, un scriptlet est un fragment d'instruction, et une expression est une expression complète du langage. En JSP chaque élément de scripting commence par » <%]. Voici la syntaxe de chacun :
L'espace est facultatif après » <%!], » <%], » <%=], et avant [%>.]
Tous ces tags s'appuient sur la norme XML ; on pourrait dire qu'une page JSP est un document XML. La syntaxe équivalente en XML pour les éléments de scripting ci-dessus serait :
De plus, il existe deux types de commentaires :
La première forme crée dans les pages sources JSP des commentaires qui n'apparaîtront jamais dans la page HTML envoyée au client. Naturellement, la deuxième forme n'est pas spécifique à JSP, c'est un commentaire HTML ordinaire. Ceci est intéressant car on peut insérer du code JSP dans un commentaire HTML, le commentaire étant inclus dans la page résultante ainsi que le résultat du code JSP.
Les déclarations servent à déclarer des variables et des méthodes dans les langages de scripting utilisés dans une page JSP (uniquement Java pour le moment). La déclaration doit être une instruction Java complète et ne doit pas écrire dans le flux out. Dans l'exemple ci-dessous Hello.jsp, les déclarations des variables loadTime, loadDate et hitCount sont toutes des instructions Java complètes qui déclarent et initialisent de nouvelle variables.
Lorsque ce programme fonctionne, on constate que les variables loadTime, loadDate et hitCount gardent leurs valeurs entre les appels de la page, il s'agit donc clairement de champs et non de variables locales.
À la fin de l'exemple un scriplet écrit « Goodbye « sur la console du serveur Web et » Cheerio « sur l'objet JspWriterimplicite out. Les scriptlets peuvent contenir tout fragment de code composé d'instructions Java valides. Les scriptlets sont exécutés au moment du traitement de la demande. Lorsque tous les fragments de scriptlet d'une page JSP donnée sont combinés dans l'ordre où ils apparaissent dans la page JSP, ils doivent contenir une instruction valide telle que définie dans le langage de programmation Java. Le fait qu'ils écrivent ou pas dans le flux out dépend du code du scriplet. Il faut garder à l'esprit que les scriplets peuvent produire des effets de bord en modifiant les objets se trouvant dans leur champ de visibilité.
Les expressions JSP sont mêlées au code HTML dans la section médiane de Hello.jsp. Les expressions doivent être des instructions Java complètes, qui sont évaluées, traduites en String, et envoyées à out. Si le résultat d'une expression ne peut pas être traduit en String alors une exception ClassCastException est lancée.
L'exemple suivant ressemble à un autre vu précédemment dans la section servlet. La première fois que la page est appelée il détecte s'il n'existe pas de champ et renvoie une page contenant un formulaire, en utilisant le même code que dans l'exemple de la servlet, mais au format JSP. Lorsque le formulaire contenant des champs remplis est envoyé à la même URL JSP, il détecte les champs et les affiche. C'est une technique agréable parce qu'elle permet d'avoir dans un seul fichier, le formulaire destiné au client et le code de réponse pour cette page, ce qui rend les choses plus simples à créer et maintenir.
Ce qui est intéressant dans cet exemple est de montrer comment le code scriptlet et le code HTML peuvent être entremêlés, au point de générer une page HTML à l'intérieur d'une boucle Java for. En particulier ceci est très pratique pour construire tout type de formulaire qui sans cela nécessiterait du code HTML répétitif.
En cherchant dans la documentation HTML des servlets et des JSP, on trouve des fonctionnalités donnant des informations à propos de la servlet ou de la page JSP actuellement en cours. L'exemple suivant montre quelques-unes de ces données.
Cet exemple montre également l'utilisation du mélange de code HTML et d'écriture sur out pour fabriquer la page HTML résultante.
La première information générée est le nom de la servlet, probablement » JSP « mais cela dépend de votre implémentation. On peut voir également la version courante du conteneur de servlet au moyen de l'objet application. Pour finir, après avoir déclaré les attributs de la session, les noms d'attributs sont affichés avec une certaine visibilité. On n'utilise pas beaucoup les visibilités dans la plupart des programmes JSP ; on les a montré ici simplement pour donner de l'intérêt à l'exemple. Il existe quatre attributs de visibilité, qui sont : la visibilité de page (visibilité 1), la visibilité de demande (visibilité 2), la visibilité de session (visibilité 3 : ici, le seul élément disponible dans la visibilité de session est » My dog, « ajouté juste après la boucle for), et la visibilité d'application (visibilité 4), basée sur l'objet ServletContext. Il existe un ServletContext pour chaque application » Web tournant sur une Machine Virtuelle Java (une application » Web est une collection de servlets et de contenus placés dans un sous-ensemble spécifique de l'espace de nommage de l'URL serveur tel que /catalog. Ceci est généralement réalisé au moyen d'un fichier de configuration). Au niveau de visibilité de l'application on peut voir des objets représentant les chemins du répertoire de travail et du répertoire temporaire.
Les sessions ont été introduites dans les sections précédentes à propos des servlets, et sont également disponibles dans les JSP. L'exemple suivant utilise l'objet session et permet de superviser le temps au bout duquel la session deviendra invalide.
