La technologie des JSP est basée sur celle des servlets et lui est complémentaire. Elle est décrite dans la spécification JSP 1.3 (http://java.sun.com/products/jsp/). Pendant que les servlets sont adaptées aux traitements coté serveur, mais le sont un peu moins pour la génération de contenu pour le client, les pages JSP se prédestinent à la génération de contenu et sont moins adaptées aux traitements complexes au niveau du serveur. Une page JSP peut cependant faire appel à d'autres objets (des javabeans) qui encapsulent des traitements complexes tout comme elle peut faire appel à une servlet ou tout autre ressource.

Le principal avantage des JSP est la séparation entre, d'un coté, la conception et développement du contenu et, de l'autre, la conception et développement de la logique d'affaires. Ces deux activités sont fortement couplées dans les servlets, ce qui ne favorise pas la maintenance des applications.

Une page JSP est un fichier texte ayant l'extension jsp et contenant du code HTML (ou XML) mélangé avec trois types d'éléments :

1. des directives
2. des éléments de script
3. des actions

Les balises JSP, comme les balises XML, sont sensibles à la casse et les valeurs des attributs sont toujours placées entre guillemets (“…”).

Dans certaines technologies équivalentes, telles que les pages ASP, le code de la page est interprété à chaque fois que la page est demandée. Contrairement aux pages ASP, les pages JSP sont préalablement compilées. En effet, lorsqu'une page JSP est demandée pour la première fois, le conteneur web convertit la page JSP en servlet et la compile. À partir de ce moment, les requêtes adressées à la page JSP sont dirigées vers cette servlet.

Il est possible d'utiliser uniquement une ou l'autre des deux technologies, JSP ou servlets, mais, en général, on combine les deux :

1. les servlets pour l'implémentation de la logique d'affaires
2. les JSP pour ta génération de contenu

Les éléments de script permettent d'inclure des instructions Java dans une page JSP. Ces instructions peuvent être des déclarations, des expressions ou des scriptlets.

Un bloc de déclaration a la forme suivante:

<%
   //declarations de variables et de méthodes
%>

Ces variables et méthodes sont traduites en attributs et méthodes d'instance de la classe de la servlet qui va être générée. Leur portée s'étend donc à toute la page JSP, incluant la zone avant l'endroit de la déclaration. Pour des raisons de lisibilité, on peut donc regrouper toutes les déclarations dans un seul bloc au début de la page JSP.

Une variable déclarée dans un bloc de déclaration devient un attribut d'instance de la servlet. Comme c'est l'unique instance qui répond à toutes les requêtes adressées à la servlet, cet attribut va être partagé par tous les clients. Il faut donc réfléchir à deux fois avant de déclarer une variable dans un bloc de déclaration.

Un bloc de déclaration ne doit pas contenir d'instruction d'écriture sur le flux de sortie vers le client.

On peut évaluer une expression et envoyer sa valeur directement vers le client. Pour cela, on place l'expression entre <%= et %>. L'expression ne doit pas se terminer par un point-virgule (;). Si le résultat de l'expression est un objet, il est converti en chaîne de caractères à l'aide de la méthode toString().

Un scriptlet est un code Java placé dans une page JSP entre les balises <% et %>. On peut avoir plusieurs scriptlets dans une même page JSP. Le code des scriptlets est placé dans la méthode service() de la servlet générée.

On peut documenter un code Java inséré dans une page JSP. Pour cela, on place des commentaires entre <%– et –%>. Contrairement aux commentaires HTML, ces commentaires ne sont pas envoyés au client.

Une directive affecte la page JSP où elle est placée et uniquement cette page. Par conséquent, elle affecte la structure entière de la servlet résultante. Une directive ne produit pas de sortie vers le client. Une directive se présente sous la forme

<%@ nom directive attribut1 = "valeur1" attribut2 = "valeur2" ...%>

Il existe trois principales directives : page, include et taglib. La directive taglib sera étudiée dans la section sur les extensions de balise. Les deux autres sont présentées ci-après.

Cette directive demande au conteneur web de remplacer ta directive elle-même par le contenu de la ressource spécifiée dans l'attribut file. La syntaxe est

<%@ include file="nom fichier" %>

Le chemin du fichier est spécifié relativement au dossier racine de l'application. Il commence donc par le caractère slash (/). Le fichier n'est pas forcément dans un dossier public et peut être une autre page JSP, une page HTML ou n'importe quelle ressource textuelle. Exemple: une page affichant un pied de page (par exemple: @ Joe Bloe 2004). Ça peut être une page HTML ou une page JSP recevant la couleur des caractères comme paramètre.

On peut placer autant de directives page dans une page JSP. Mais, à l'exception de import, un même attribut ne doit apparaître qu'une seule fois.

Durant la translation de la page JSP en servlet, les directives page sont assimilées et appliquées ensemble à la page. On peut donc les placer n'importe où dans la page. Par convention, on le place au début.

Les principaux attributs sont

• import → liste de packages importés par la page. Les noms des packages sont séparés par des virgules (,).
• session → a la valeur true par défaut et ça indique que ta page participe à la session courante. L'objet session est alors disponible pour cette page.
• buffer → est la taille du buffer utilisé par la page. Si sa valeur est none, la page n'a pas de buffer. Autrement, sa valeur est de ta forme <entier>kb (exemple : 8kb, 12kb, 64kb, etc) et représente la taille du buffer en kilo-octets. La valeur par défaut est 8kb.
• autoFlush → stratégie de vidage du buffer. Si sa valeur est true, le contenu du buffer est automatiquement envoyé au client dès qu'il est plein. Si sa valeur est false, lorsque le buffer est plein, une exception est déclenchée. Cet attribut ne peut pas avoir ta valeur false si l'attribut buffer est à none.
• errorPage → URL d'une page JSP de la même application. Cette page sera invoquée automatiquement en cas d'exception. De plus, cette page reçoit l'objet Throwable qui représente l'exception déclenchée.
• contentType → indique te type MIME et te jeu de caractères utilises pour la réponse de la page JSP.
• language → la valeur par défaut est Java. Sera utilisé lorsque les conteneurs JSP supporteront plusieurs langages.
• extends → nom complet de la classe de laquelle la page JSP (en fait la classe servlet correspondante) doit dériver (par héritage, bien entendu). Cet attribut est rarement utilisé.

Voici un exempte de directive page qui importe le package nécessaire pour exploiter l'API JDBC:

<%@ page import="java.sql.*" %>

Plusieurs objets sont automatiquement créés et rendus disponibles pour une page JSP. Ces objets implicites sont basés sur l'API des servtets et sont

• request → de type ServletRequest (en général de type HttpServletRequest). Il représente la requête du client. Il est de portée requête.
• response → de type HttpServletResponse et représente la réponse à envoyer au client. Il est de portée page.
• out → c'est le flux de sortie vers te client. Il est de type JspWriter, qui, comme PrintWriter, est une classe dérivée de java.io.Writer. JspWriter est une version bufferée de PrintWriter. L'objet out est de portée page.
• session → de type HttpSession et représente l'objet session. Il est créé automatiquement sauf si dans la directive page l'attribut session est à false. Il est de portée session.
• application → de type ServletContext. Il représente le contexte de l'application web. Il est de portée application.
• page → c'est l'instance de la classe de la servlet correspondant à la page JSP. page est l'objet this de la page JSP courante. Il est de portée page.
• pageContext → de type javax.servlet.jsp.PageContext. Il contient les données utilisées dans toute la page. Il est de portée page.
• config → de type ServletConfig. Il représente la configuration de la page. Il est de portée page.

Qu'un objet soit implicite ou instance d'une classe personnelle, il possède une portée. Cette portée définit la zone dans laquelle l'objet est disponible ainsi qu'à quel moment il est créé et détruit. Il existe quatre portées possibles pour un objet : page, requête, session et application.

Un objet avec ta portée page existe dans la page JSP courante. Il disparaît dès qu'on quitte la page.

Un objet avec la portée requête existe aussi longtemps que la requête existe. En particulier, lorsque la page JSP inclut le traitement d'une autre ressource (avec l'action <jsp:include>) ou lui redirige la requête (avec l'action <jsp:forward>), l'objet sera disponible pour cette ressource.

Un objet avec la portée session existe aussi longtemps que l'objet session existe, c'est à dire aussi longtemps que le client est connecté au site web. Les autres pages JSP qui interviennent dans la session du client ont accès à un tel objet.

Un objet avec ta portée application existe aussi longtemps que l'application est en fonction.

Les actions affectent le comportement à l'exécution de la page JSP. On distingue

1. les actions standard : ce sont des actions implémentées par défaut par le conteneur web.
2. les balises personnalisées.

Cette section présente les actions standard. Les balises personnalisées seront considérées dans la section sur les extensions de balise.

Lorsque le conteneur web rencontre une balise d'action standard, durand la conversion de la page JSP en servlet, il génère le code Java correspondant à l'action.

Les action standards sont :

• <jsp:include>
• <jsp:forward>
• <jsp:param>
• <jsp:useBean>
• <jsp:setProperty>
• <jsp:getProperty>
• <jsp:plugin>

Les actions <jsp:useBean>, <jsp:setProperty> et <jsp:getProperty> seront étudiées dans la section sur les Javabeans. Les autres sont présentées ci-dessous.

Cette action s'utilise dans le corps d'une des actions <jsp:include> ou <jsp:forward> pour transmettre des paramètres additionnels à la requête du client. La syntaxe est :

<jsp:param name="rom_paramètre" value="valeur_paramètre" />

Une ressource statique (une page HTML, par exemple) ou dynamique (page JSP ou servlet, par exemple) peut être incluse dans une page JSP. On utilise pour cela l'action <jsp:include> en spécifiant l'URL de la ressource à inclure. La ressource demandée n'a cependant accès qu'au flux de sortie vers le client.

Cette action fonctionne comme la méthode include() de RequestDispatcher utilisée dans la collaboration entre une servlet et une autre ressource.

La syntaxe se présente sous deux formes possibles :

<jsp:include paqe="URL_ressource" flush="true" />

Ou :

<jsp:include paqe="URL_ressource" flush="true">
<jsp:param name="nom_param1" value="valeur_paraml" />
<jsp:param name="nom_param2" value="valeur_param2" />
</jsp:include>

où flush est un attribut optionnel, valant false par défaut, qui indique si le buffer du flux de sortie doit être « flushé » avant d'inclure la ressource. Cet attribut n'a d'effet que si le flux de sortie est « bufferé » (ce qui est le cas par défaut comme on l'a vu dans l'attribut buffer de ta directive page). Il faut savoir qu'une fois le buffer flushé, il n'est plus possible de rediriger le client vers une autre ressource (par un forward) ou vers une page d'erreur.

La différence entre la directive <%@ include %> et l'action <jsp:include> est importante : avec la directive, la ressource est incluse à la compilation. Donc si on modifie la ressource, il faut recompiler la page qui l'a incluse. Tandis qu'avec l'action, la ressource est traitée lors du traitement de la requête. Il est conseillé de n'utiliser la directive include que pour inclure des ressources qui changent rarement.

Cette action permet de rediriger la requête du client vers une autre ressource statique (une page HTML) ou dynamique (une page JSP ou une servlet). La ressource doit faire partie de la même application web.

La syntaxe se présente sous deux formes possibles :

<jsp:forward page="URL_ressource" />

ou:

<jsp:forward page="URL_ressource">
<jsp:param name="nom_param1" value="valeur_paraml" />
<jsp:param name="nom_param2" value="valeur_param2" />
</jsp:forward>

Lorsque cette action est rencontrée, l'exécution de la page JSP est interrompu et son buffer est vidé. Ensuite, la requête est modifiée en intégrant les nouveaux paramètres spécifiés dans le corps de l'action à l'aide des actions <jsp:param>. La requête est transmise vers la ressource.

Le comportement de cette action est le même que la méthode forward() de RequestDispatcher utilisée dans la collaboration entre une servlet et une autre ressource.

Permet d'invoquer un plug-in au niveau du navigateur du client. Cette action génère une balise spécifique au navigateur (<EMBED> pour Netscape Navigator, <OBJECT> pour Internet Explorer).

Un Javabean est un objet dont le format est standardisé. Dans une page JSP, une façon de séparer le code de la présentation consiste à encapsuler la logique dans un Javabean. On crée le Javabean en instanciant la classe correspondante à l'aide de l'action <jsp:useBean>. L'objet est ensuite disponible dans la portée qui lui est associée. En particulier, on peut accéder aux propriétés de l'objet à l'aide des actions <jsp:setProperty> et <jsp:getProperty>. En réalité, l'action <jsp:useBean> peut soit créer une instance de Javabean ou référencer une instance existante. Cette action se présente sous deux formes : sans corps et avec corps.

<jsp:useBean id="nom_bean" scope="portee" details />

ou :

<jsp:useBean id="nom_bean" scope="portee" details >
Corps
</jsp:useBean>

Le corps peut être n'importe quel contenu JSP. Souvent, il se présente sous forme de scriptlets et d'actions <jsp:setProperty>. Le corps est évalué lorsque le bean est instancié et sert à configurer le nouveau bean.

Les détails se présentent sous une des quatre formes suivantes :

• class = “nom-classe”
• class = “nom-classe” type = “nom-type”
• beanName = “nom_bean” type = “nom_type”
• type = “nom-type”

nom-classe est le nom de la classe dont le bean est une instance. nom-type est te type du bean créé. Par exemple, on peut avoir une classe Etudiant qui dérive d'une classe Personne :

public class Etudiant extends Personne

Tout comme on peut créer une variable de type Personne qui référence un objet de type Etudiant :

Personne p = new Etudiant();

On peut créer un bean de type Personne qui référence un objet Etudiant :

<jsp:useBean: id="p" class ="Etudiant" type="Personne" />

La spécification 1.1 des pages JSP a introduit une amélioration majeure dans l'architecture des JSP en offrant au programmeur la possibilité de définir des bibliothèques de balises personnalisées. Ces balises fonctionnent comme les actions standards sauf que c'est le programmeur qui spécifie le code java qui sera exécuté lorsque la balise est rencontrée dans une page JSP. La séparation entre la présentation et le traitement se trouve nettement améliorée puisque le programmeur peut encapsuler son code dans des blocs utilisables directement par le concepteur web.

Comme les balises d'actions standard, une balise personnalisée :

• peut avoir des attributs. Par exemple, le travail réalisé par la servlet TableMult peut être realisé par une balise tablemult avec un préfixe sg et qui possède un attribut nb représentant le nombre dont on affiche la table de multiplication. Dans une page JSP, cette balise s'écrira <sg:tablemult nb=“7” />.
• peut imbriquer des sous-balises et la balise peut coopérer avec ses sous-balises.
• peut avoir un corps. Le corps d'une balise est tout le contenu qui se trouve entre les balises de début et de fin, hormis les sous-balises : <sg:tablemult nb=“7”>Corps</sg:tablemult>.
• peut définir des variables de script qui, en fonction de leur portée, peuvent être valables après la fermeture de la balise.

Le développement d'une bibliothèque de balises personnalisées se fait en 3 étapes:

1. Décrire les balises qui feront partie de la bibliothèque.
2. Créer le descripteur de bibliothèque de balises.
3. Écrire le gestionnaire de balise pour chacune des balises de la bibliothèque.

Pour illustrer le processus de création de l'utilisation de bibliothèque de balises, nous allons créer une bibliothèque contenant deux balises :

1. Une balise simple qui affiche un message de bienvenue <mabiblio:salut />.
2. Une balise qui produit une table de multiplication. La balise va posséder un attribut nb qui va représenter le nombre pour lequel on va produire la table de multiplication : <mabiblio:tablemult nb=“9” />.

Créer le descripteur de la bibliothèque. Celui-ci est un fichier XML qui décrit la bibliothèque et chacune de ses balises. Par convention, le descripteur de déploiement porte l'extension tld. Dans notre exemple, nous allons t'appeler mabiblio.tld. Voici son contenu :

<?xml version="l.0" encoding="ISO-8859-1"?>
<!DOCTYPE taglib
  PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN" "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd">
<taglib>
  <tlib-version>1. 0</tlib-version>
  <jsp-version>1.2</jsp-version>
  <short-name>mabiblio</short-name>
  <description>Un exemple de bibliothèque de balises personnelles (tag extension library)</description>
  <tag>
    <name>salut</name>
    <tag-class>tagext.SalutTag</tag-class>
    <bodycontent>empty</body-content>
    <description>Un exemple de balise qui affiche un message de bienvenue.</description>
  </tag>
  <tag>
    <name>Tablemult</name>
    <tag-class>tagext.TableMultTag</tag-class>
    <body-content>empty</body-content>
    <description>Un exemple de balise qui affiche une table de multiplication.</description>
    <attribute>
      <name>nb</name>
      <required>true</required>
      <rtexprvalue>true</rtexprvalue>
    </attribute>
  </tag>
</taglib>

Remarquez que nous avons déjà choisi les noms des classes qui vont être des gestionnaires de nos balises : SalutTag pour ta balise salut et TableMultTag pour la balise tablemult. Les deux classes seront dans un package que nous avons choisi d'appeler tagext.

Remarquez aussi que nous avons indiqué que la balise tablemult va posséder un attribut nb, que celui-ci est obligatoire et que sa valeur peut être fournie sous forme d'une expression JSP (<%=…%>).

Remarquez, enfin, que nous avons indiqué que nos 2 balises n'ont pas de corps : <body-content>empty</body-content>.

Le gestionnaire d'une balise (tag handler) est la classe qui va contenir le code qui sera exécuté lorsque la balise est rencontrée dans une page JSP.

Pour supporter le développement de gestionnaires de balises personnalisées, l'API J2EE fournit les classes et interfaces représentées sur la figure ci-dessous (rappelons que tes noms d'interfaces sont écrits en italique). Ces classes et interfaces sont dans le package javax.servlet.jsp.tagext, qui contient la partie de l'API relative aux extensions de balises.

Chaque gestionnaire de balise doit implémenter l'interface Tag qui fournit le contrat entre une balise simple, sans corps, et la page JSP qui l'utilise.

L'interface IterationTag étend l'interface Tag et représente une balise qui peut avoir un corps. Elle fournit, en plus des méthodes héritées de Tag, une méthode permettant d'itérer un traitement sur le corps de la balise.

L'API fournit la classe TagSupport qui implémente l'interface IterationTag. Pour définir des gestionnaires pour des balises simples, il est plus simple d'étendre la classe TagSupport, plutôt que d'implémenter l'interface Tag ou IterationTag. C'est ce que nous allons faire avec notre première balise salut :

package tagex;
public class Salut-Tag extends TaqSupport

Le gestionnaire d'une balise qui veut manipuler son corps doit implémenter l'interface BodyTag, qui hérite de l'interface IterationTag. Là aussi, l'API fournit la classe d'implémentation BodyTagSupport. Il est plus simple de faire dériver son gestionnaire de BodyTagSupport plutôt que de lui faire implémenter l'interface BodyTag.

Voici maintenant le gestionnaire de la balise salut :

import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
import java.io.IOException;
 
public class SalutTag extends TagSupport {
    public int doStartTag() throws JspTagException {
        return EVAL_BODY_INCLUDE;   // évaluer le contenu du corps, s'il existe.
        //autre valeur possible à retourner SKIP-BODY (ignorer le corps)
    }
 
    public int doEndTag() throws JspTagException {
        try {
            JspWriter out = pageContext.getOut();
            out.println("Bonjour et bienvenue");
        }
        catch (IOException e) {
            throw new JspTagException("impossible d\'écrire sur le flux de sortie de la page JSP.");
            return EVAL_PAGE; //évaluer la suite de la page JSP, si elle existe.
            //aure valeur possible à retourner : SKIP_PAGE (ignorer la suite de la page)
        }
    }
}

Avant d'utiliser une bibliothèque de balises dans une application, il faut :

1. Copier tous les packages ou fichiers de classes dans le dossier WEB-INF/classes de l'application. Souvent, ces fichiers sont dans un fichier JAR, il suffit alors de copier ce fichier dans le dossier WEB-INF/classes tel quel, sans décompresser.
2. Copier le descripteur de bibliothèque (mabiblio.tld, dans notre exemple) dans le dossier WEB-INF de l'application. Par convention, on le met dans le sous-dossier WEB-INF/tlds.
3. Et enfin, déclarer la bibliothèque dans le descripteur de déploiement web.xml de l'application en lui attribuant une URI et en spécifiant le chemin vers son descripteur de bibliothèque :

<web-app>
  <taglib>
    <taglib-uri>/bibliol</taglib-uri>
    <taglib-location>/WEB-INF/tlds/mabiblio.tld</taglib-location>
  </taglib>
</web-app>

La bibliothèque doit ensuite être importée dans la page JSP qui veut l'utiliser. On utilise pour cela la directive <%@ taglib %> :

<%@ taglib uri="/bibliol" prefix="abc" %>
...
<abc:salut />

C'est l'occasion alors de lui attribuer un préfixe. En particulier, ce préfixe va servir pour distinguer entre deux balises de même nom contenues dans deux bibliothèques importées par la page JSP. Si, par exemple, la page JSP importe une deuxième bibliothèque fournie par une partie tierce et qui contient aussi une balise de nom salut :

<%@ taglib uri="/biblio1" prefix="abc" %>
<%@ taglib uri="/biblic2" prefix="xyz" %>

Alors, ce sont les préfixes qui permettent de distinguer entre la balise salut de la première bibliothèque (qui sera désignée par <abc:salut>) et la balise salut de la deuxième bibliothèque (qui sera désignée par <xyz:salut>).

Une balise peut avoir un ou plusieurs attributs. C'est le cas de la balise tablemult que nous avons décrit dans la section ci-dessus et qui possède un attribut nb représentant le nombre pour lequel on veut produire la table de multiplication :

<sg:tablemult nb="19" />

Pour permettre à une balise d'avoir des attributs, il faut les déclarer dans le descripteur de bibliothèque. Pour chaque attribut, il faut spécifier le nom, s'il est obligatoire ou non et si sa valeur peut être fournie sous forme du résultat d'une expression :

  <tag>
    <name>Tablemult</name>
    <tag-class>tagext.TableMultTag</tag-class>
    <body-content>empty</body-content>
    <description>Un exemple de balise qui affiche une table de multiplication.</description>
    <attribute>
      <name>nb</name>
      <required>true</required>
      <rtexprvalue>true</rtexprvalue>
    </attribute>
  </tag>

Il faut aussi ajouter dans le gestionnaire de balise un attribut de même nom et sa méthode d'accès en écriture (son setter)

public class TableMultTag extends TagSupport {
 
    private int nb;
 
    public void setNb(Strincj s) {
        if (s != null)
            nb = Inteqer.parseInt(s);
        else
            nb = 0;
    }
}

Cette méthode est invoquée automatiquement dès que l'attribut est rencontré dans la balise.

Les balises simples, dont les gestionnaires dérivent de TagSupport, permettent de définir des traitements simples qui sont réalisés lorsque la balise est rencontrée dans une page JSP. Cependant, la veritable puissance des extensions de balises vient de leur capacité à interagir avec leur corps et leurs sous-balises. Il devient alors possible d'effectuer des traitements sur le corps d'une balise et aussi de faire coopérer la balise avec ses sous balises pour réaliser des traitements complexes.

Le gestionnaire d'une balise qui doit travailler sur son corps ou avec ses sous balises est une classe qui implémente l'interface BodyTag. En pratique, il est plus simple d'étendre la classe BodyTagSupport qui implémente déjà l'interface BodyTag.

Au début du traitement du corps, stockage du flux de sortie actuel et création d'un autre flux de type BodyContent. La variable de script out ainsi que la valeur retournée par pageContext.getOut() référent à ce nouveau flux. Lorsque plusieurs balises sont imbriquées, ces flux sont stockés dans une pile.

BodyContent est une sous-classe de JspWriter qui utilise automatiquement un buffer. Toutes les opérations de sortie sont accumulées dans ce buffer. À la fin du traitement du corps, le flux original est restauré mais le flux de type BodyContent est toujours disponible dans ta méthode doEndTag() car il est référencé par un attribut de nom bodyContent. Le contenu de ce flux peut être récupéré à l'aide d'une des deux méthodes getString() ou getReader() pour être envoyé vers le client après d'éventuelles retouches.

    <servlet>
        <servlet-name>Profile</servlet-name>
        <jsp-file>/profile.jsp</jsp-file>
    </servlet>
 
    <servlet-mapping>
        <servlet-name>Profile</servlet-name>
        <url-pattern>/profile</url-pattern>
    </servlet-mapping>

• http://jakarta.apache.org/taglibs/