Serveur d'impression

Développer en Java – Pages de serveur Java (JSP) – Bien choisir son serveur d impression

Par Titanfall , le 3 mai 2019 - 48 minutes de lecture

Niveau: niveau 4 Supérieur

Les pages de serveur Java (JSP) sont une technologie Java permettant de générer des pages Web dynamiques.

La technologie JSP est utilisée pour séparer la présentation en code HTML et les processus écrits en Java en tant que JavaBeans ou servlets. Cela est d'autant plus facile que les JSP définissent une syntaxe particulière pour l'appel d'un bean et l'insertion dynamique du résultat de son traitement dans la page HTML.

Les informations de ce chapitre concernent les spécifications JSP 1.0 et ultérieures.

Ce chapitre contient plusieurs sections:


Les JSP vous permettent d'introduire du code Java dans des balises prédéfinies d'une page HTML. La technologie JSP allie la puissance Java côté serveur à la facilité de disposition HTML du côté client.

La page officielle de cette technologie est à l'adresse suivante:
http://www.oracle.com/technetwork/java/javaee/jsp/index.html.

Un JSP est généralement composé de:

  • balises de données et HTML
  • Balises JSP
  • scriptlets (code Java intégré dans le JSP)

Les fichiers JSP ont l'extension .jsp par convention.

Concrètement, les JSP sont basés sur des servlets. Lors du premier appel de la page JSP, le moteur JSP génère et compile automatiquement le servlet qui permet la génération de la page Web. Le code HTML est entièrement inclus dans le servlet. Le code Java est inséré dans le servlet.

Le servlet généré est compilé, enregistré et exécuté. Les appels suivants depuis le JSP sont beaucoup plus rapides car la servlet, conservée par le serveur, est exécutée directement.

Il existe plusieurs façons de combiner les technologies JSP, les EJB et les servlets pour développer des applications Web.

Étant donné que le code de servlet est généré de manière dynamique, les JSP sont relativement difficiles à déboguer.

Cette approche présente toutefois plusieurs avantages:

  • l'utilisation de Java par le JSP permet l'indépendance de la plate-forme
    exécution mais aussi le serveur Web utilisé.
  • séparation des traitements et présentation: la page Web peut être
    écrit par un concepteur et les balises Java peuvent être ajoutés plus tard par le
    développeur. Les traitements peuvent être faits avec des composants réutilisables
    (Haricots Java).
  • Les JSP sont basés sur des servlets: tout ce qui est fait par un servlet
    pour la génération de pages dynamiques peut être fait avec un JSP.

Il existe plusieurs versions des spécifications JSP:

Version
0,91 Première sortie
1,0

Juin 1999: première version finale
lié à l'API servlet 2.1

1.1 Décembre 1999
lié à l'API servlet 2.2
1.2 Octobre 2000, JSR 053
lié à l'API servlet 2.3
2.0 Novembre 2003, JSR 152
lié à l'API servlet 2.4
2.1 Mai 2006, JSR 245
lié à l'API servlet 2.5
2.2 Décembre 2009, version de maintenance de la JSR 245
lié à l'API servlet 3.0
2.3 Juin 2013, version de maintenance de la JSR 245
lié à l'API servlet 3.1

Sommaire

73.1.1. Le choix entre JSP et Servlets

Les servlets et les JSP ont beaucoup de choses en commun puisqu'un JSP est finalement converti en un servlet. Le choix d'utiliser l'une ou l'autre de ces technologies ou les deux doit être fait pour tirer le meilleur parti de leurs avantages.

Dans une servlet, les traitements et la présentation sont regroupés. L’aspect présentation est dans ce cas difficile à développer et à maintenir en raison de l’utilisation répétée de méthodes pour insérer le code HTML dans le flux de sortie. De plus, une simple modification du code HTML nécessite la recompilation du servlet. Avec un JSP, la séparation des traitements et de la présentation rend cela très simple et automatique.

Il est préférable d’utiliser les JSP pour générer des pages Web dynamiques.

L'utilisation des servlets est obligatoire si elles doivent communiquer directement avec une applet ou une application et non plus avec un serveur Web.

73.1.2. JSP et technologies concurrentes

Il existe plusieurs technologies dont le but est similaire aux JSP, notamment ASP, PHP et ASP.Net. Chacune de ces technologies présente des avantages et des inconvénients, dont voici une liste non exhaustive.

JSP

PHP

ASPIC

ASP.Net

la langue

Java

PHP

VBScript ou JScript

Toutes les langues supportées par .Net (C #, VB.Net, Delphi, …)

mode d'exécution

Compilé en pseudo-code (bytecode)

Interprète

Interprète

Compilé en pseudo-code (MSIL)

Principaux avantages Reposez-vous sur la plate-forme Java dont il hérite des avantages Open source
Nombreuses bibliothèques et sources d'applications gratuites disponibles
Facile à mettre en œuvre
Facile à mettre en œuvre Reposez-vous sur la plate-forme .Net dont il hérite des avantages
Wysiwyg et les événements
Code derrière pour la séparation affichage / traitement
principaux inconvénients Débogage plutôt fastidieux
Beaucoup de code à écrire
Débogage plutôt fastidieux
Beaucoup de code à écrire
support partiel de la programmation orientée objet en attente de la version 5
Débogage plutôt fastidieux
Beaucoup de code à écrire
Fonctionne principalement sur les plateformes Windows
Pas de POO, objets métier encapsulés dans des objets COM lourds à implémenter
Fonctionne principalement sur les plates-formes Windows. (Voir le projet Mono pour le support d'autres plateformes)

Dans un premier temps, Sun a fourni un kit de développement pour les JSP: le kit de développement Web du serveur Java (JSWDK). Ensuite, Sun a confié au projet Apache le développement de l’implémentation de référence du moteur JSP: le projet Tomcat. Depuis la version 2.2, l'implémentation de référence est le projet Glassfish.

Selon la version de l'API utilisée, vous devez choisir un produit différent. Le tableau ci-dessous récapitule les implémentations de référence basées sur la version de l'API implémentée.

Produit

Version

Version de l'API Servlet implémentée

Version de l'API JSP implémentée

JSWDK

1.0.1

2.1

1,0

Matou

3.2

2.2

1.1

Matou

4.0

2.3

1.2

Matou

5.0

2.4

2.0

Matou

6.0

2,5

2.1

Glassfish

3.0

3.0

2.2

Glassfish

4.0

3.1

2.3

Il est également possible d'utiliser tout conteneur Web compatible avec les spécifications de la plate-forme J2EE / Java EE. Une liste non exhaustive est fournie dans le chapitre "Outils gratuits et commerciaux".

73.2.1. Le kit de développement Web JavaServer (JSWDK) sous Windows

Le fichier JSWDK est proposé sous forme de fichier zip nommé jswdk_1_0_1-win.zip.

Pour l'installer, décompressez simplement l'archive dans un répertoire du système. Le serveur commence à exécuter le fichier startserver.bat.

Pour lancer le serveur:
C:  jswdk-1.0.1> startserver.bat

Utiliser classpath :.  Des classes;.  Webserver.jar ;.  Lib  jakarta.jar ;.  Lib  servlet.jar;.
 Lib  jsp.jar ;.  Lib  jspengine.jar ;.  Exemples  WEB-INF  jsp  beans ;.  Pages Web  WEB-INF
 Servlets ;.  Webpages  WEB-INF  jsp  beans ;.  Lib  xml.jar ;.  Lib  moo.jar  lib  tools.ja
Dr. C:  jdk1.3  lib  tools.jar;
C:  jswdk-1.0.1>

Le serveur s'exécute dans une console en arrière-plan. Cette console permet de voir les messages envoyés par le serveur.

Exemple: au démarrage
JSWDK WebServer Version 1.0.1
Configuration chargée à partir de: fichier: C:  jswdk-1.0.1  webserver.xml
noeud final créé: localhost / 127.0.0.1: 8080

Si la JSP contient une erreur, le serveur envoie une page d'erreur:

Une exception est levée et est affichée dans la fenêtre où le serveur est en cours d'exécution:

Exemple:
- Commentaires de la page JSP -
^
1 erreur
à l'adresse com.sun.jsp.compiler.Main.compile (Main.java:347)
à l'adresse com.sun.jsp.runtime.JspLoader.loadJSP (JspLoader.java:135)
à l'adresse com.sun.jsp.runtime.JspServlet $ JspServletWrapper.loadIfNecessary (JspS
ervlet.java:77)
à l'adresse com.sun.jsp.runtime.JspServlet $ JspServletWrapper.service (JspServlet.j
ava: 87)
à l'adresse com.sun.jsp.runtime.JspServlet.serviceJspFile (JspServlet.java:218)
à l'adresse com.sun.jsp.runtime.JspServlet.service (JspServlet.java:294)
à l'adresse javax.servlet.http.HttpServlet.service (HttpServlet.java:840)
à l'adresse com.sun.web.core.ServletWrapper.handleRequest (ServletWrapper.java:155
)
à l'adresse com.sun.web.core.Context.handleRequest (Context.java:414)
à l'adresse com.sun.web.server.ConnectionHandler.run (ConnectionHandler.java:139)
PROBLEME DE FIL SUIVANT: java.io.IOException: socket fermé
java.io.IOException: socket fermé
sur java.net.PlainSocketImpl.getInputStream (Source inconnue)
at java.net.Socket $ 1.run (Source inconnue)
at java.security.AccessController.doPrivileged (Native Method)
at java.net.Socket.getInputStream (Source inconnue)
à l'adresse com.sun.web.server.ConnectionHandler.run (ConnectionHandler.java:161)

Le répertoire de travail contient le code et le bytecode des servlets générés à partir des JSP.

Pour arrêter le serveur, exécutez simplement le script stopserver.bat.

Lorsque le serveur s'arrête, le répertoire de travail contenant les servlets générés à partir des fichiers JSP est supprimé.

73.2.2. Le serveur Tomcat

La mise en oeuvre et l’utilisation de Tomcat sont détaillées dans une section du chapitre. "Servlets".

Une grande partie du contenu d'une JSP est constituée de code HTML. De plus, la méthode la plus simple pour écrire un fichier JSP consiste à écrire le fichier HTML avec un outil dédié, puis à ajouter les balises JSP pour les pièces dynamiques.

La seule restriction sur HTML est l'utilisation de fragments " <% " et " %> Dans ce cas, le moyen le plus simple consiste à utiliser les caractères spéciaux HTML & lt; et & gt; sinon, l'analyseur de moteur JSP considère qu'il s'agit de balises JSP et renvoie une erreur.

Exemple:


Tester


Plusieurs balises JSP commencent par <% et se terminent par% & gt;

Il existe trois types de tags:

  • balises directive: elles permettent de contrôler la structure du servlet
    généré
  • balises de script: elles permettent d'insérer du code Java dans le servlet
  • balises d'action: elles facilitent l'utilisation de composants
stop "height =" 42 "width =" 42 Avertissement: Les noms de balises sont sensibles à la casse.

73.4.1. Les balises directives <%@ ... %>

Les directives vous permettent de spécifier des informations globales sur la page JSP. Les spécifications JSP définissent trois directives:

  • page: Définir les options de configuration
  • include: permet d'inclure des fichiers statiques dans le fichier JSP avant la génération.
    de la servlet
  • taglib: permet de définir des tags personnalisés

Leur syntaxe est la suivante:

<% @ Directif attribut= "valeur"…%>

73.4.1.1. La directive de page

Cette directive doit être utilisée dans toutes les pages JSP: elle vous permet de définir des options s’appliquant à l’ensemble du JSP.

Il peut être placé n'importe où dans la source mais il est préférable de le mettre au début du fichier, même avant la balise. . Il peut être utilisé plusieurs fois dans la même page, mais il ne doit définir la valeur d'une option qu'une seule fois, à l'exception de l'option d'importation.

Les options définies par cette directive sont de la forme option = valeur.

Option

Valeur

Valeur par défaut

Autre valeur possible

autoFlush

Chaîne

"Vrai"

"Faux"

tampon

Chaîne

"8kb"

"Aucun" ou "nnnkb" (nnn indiquant la valeur)

contentType

Une chaîne contenant le type MIME

errorPage

Une chaîne contenant une URL

s'étend

Une classe

importation

Une classe ou un package. *

Info

Chaîne

isErrorPage

Chaîne

"Faux"

"Vrai"

isThreadSafe

Chaîne

"Vrai"

"Faux"

la langue

Chaîne

"Java"

session

Chaîne

"Vrai"

"Faux"

Exemple:
<%@ page import="java.util.*" %>
<%@ page import="java.util.Vector" %>
<%@ page info="Ma premiere JSP"%>

Les options sont:

  • autoFlush = "vrai| Faux "

    Cette option spécifie si le flux de sortie du servlet doit être vidé lorsque
    le tampon est plein. Si la valeur est false, une exception est levée dès que
    le tampon est plein. Nous ne pouvons pas définir false si la valeur du tampon est
    aucun.

  • tampon = "aucun |8kb|Taillekb "

    Cette option permet de spécifier la taille de la mémoire tampon des données générées contenues
    par l'objet de type JspWriter.

  • contentType = "mimeType [;charset=[;charset=[;charset=[;charset=jeu de caractères ]"
    | "text / html; jeu de caractères = ISO-8859-1"

    Cette option spécifie le type MIME des données générées.

    Cette option est équivalente à <% response.setContentType("mimeType"); %>

  • errorPage ="RelativeURL"

    Cette option vous permet de spécifier le JSP appelé en cas d’exception.
    levage

    Si l'URL ne commence pas par & # 39; / & # 39 ;, alors l'URL est relative au répertoire
    serveur Web principal sinon il est relatif au répertoire qui contient
    le JSP

  • s'étend= "Package.class"

    Cette option vous permet de spécifier la classe qui sera la super classe de l'objet
    Java créé à partir du JSP.

  • import = " paquet. * , … "

    Cette option importe les classes contenues dans les packages utilisés.
    dans le code du JSP. Cette option est utilisée comme instruction d'importation
    dans un code source Java.

    Chaque classe ou package est séparé par une virgule.

    Cette option peut être présente dans plusieurs directives de page.

  • info = "text"

    Cette option vous permet de spécifier une petite description du fichier JSP. Le texte fourni
    sera renvoyé par la méthode getServletInfo () du servlet généré.

  • isErrorPage = "true |faux"

    Cette option spécifie si le JSP génère une page d'erreur. La valeur
    true permet à l'objet Exception d'être utilisé dans le JSP

  • isThreadSafe = "vrai| Faux "

    Cette option indique si le servlet généré sera multithread: dans ce cas,
    la même instance du servlet peut gérer plusieurs demandes simultanément.
    En retour, il doit gérer correctement les accès concurrents aux ressources.
    La valeur false amène le servlet généré à implémenter l'interface SingleThreadModel.

  • language = "java"

    Cette option définit le langage utilisé pour écrire du code dans le JSP. le
    la seule valeur actuellement autorisée est "java".

  • session = "vrai| faux"

    Cette option spécifie si le JSP est inclus dans une session ou si
    non. La valeur par défaut (true) permet l'utilisation d'un objet de session de
    Type HttpSession qui gère les informations dans une session.

73.4.1.2. La directive include

Cette directive vous permet d'inclure un fichier dans le code source JSP. Le fichier inclus peut être un extrait de code JSP, HTML ou Java. Le fichier est inclus dans le JSP avant d'être interprété par le moteur JSP.

Cette balise est particulièrement utile pour insérer un élément multi-page commun tel qu'un en-tête ou un pied de page.

Si le fichier inclus est un fichier HTML, il ne doit pas contenir de balise. , , ou ce qui dupliquerait ceux présents dans le fichier JSP. Cela nécessite l'écriture de fichiers HTML particuliers uniquement pour être inclus dans les JSP: ils ne peuvent pas être utilisés seuls.

La syntaxe est la suivante:

<%@ include file="chemin relatif du fichier" %>

Si le chemin commence par & # 39; / # 39 ;, le chemin est relatif au contexte de l'application, sinon il est relatif au fichier JSP.

Exemple:
hello.htm:

BONJOUR

Exemple: Test1.jsp


Test de page JSP


Test d'inclusion d'un fichier dans le JSP

<%@ include file="bonjour.htm"%>

fin

Pour tester cette JSP avec le JSWDK, placez simplement ces deux fichiers dans le répertoire jswdk-1.0.1 examples jsp test.

Pour afficher le fichier JSP, entrez l'URL http: // localhost: 8080 / examples / jsp / test / Test1.jsp dans un navigateur.

stop "height =" 42 "width =" 42 Attention: une modification du fichier inclus ne provoque pas de régénération
et une compilation du servlet correspondant au JSP. Pour insérer un
fichier dynamiquement lors de l'exécution du servlet, il est nécessaire d'utiliser la balise
.

73.4.1.3. La directive taglib

Cette directive déclare l'utilisation d'une bibliothèque de balises personnalisée. L'utilisation de cette directive est détaillée dans la section consacrée aux bibliothèques de balises personnalisées.

73.4.2. Tags de script

Ces balises sont utilisées pour insérer du code Java qui sera inclus dans le servlet généré à partir du JSP. Il existe trois balises pour l'insertion de code Java:

  • la balise de déclaration: le code Java est inclus dans le corps du servlet
    généré. Ce code peut être la déclaration de variables d'instance ou de classe ou la déclaration de méthodes.
  • la balise expression: évalue une expression et insère le résultat dans la forme
    chaîne dans la page Web générée.
  • la balise scriptlets: Par défaut, le code Java est inclus dans la méthode service () du servlet.

Il est possible d'utiliser dans ces balises plusieurs objets définis par les JSP.

73.4.2.1. La balise de déclaration <%! ... %>

Cette balise est utilisée pour déclarer des variables ou des méthodes pouvant être utilisées dans le JSP. Il ne génère aucun caractère dans le fichier HTML de sortie.

La syntaxe est la suivante:

<%! declarations %>

Exemple:
<%! int i = 0; %> 
<%! dateDuJour = new java.util.Date(); %>

Les variables déclarées de cette manière peuvent être utilisées dans les balises d'expression et de scriptlet.

Il est possible de déclarer plusieurs variables dans la même balise en les séparant avec & # 39 ;; & # 39; personnages.

Cette balise vous permet également d’insérer des méthodes dans le corps du servlet.

Exemple:


Tester





<%!
int minimum (int val1, int val2) 
si (val1 < val2) return val1;
   else return val2;
 
%> 
<% int petit = minimum(5,3);%>

Le plus petit des 5 et 3 est <%= petit %>

73.4.2.2. La balise d'expression <%= ... %>

Le moteur JSP remplace cette balise par le résultat de l'évaluation de l'expression présente dans la balise.

Ce résultat est toujours converti en chaîne. Cette balise est un raccourci pour éviter d’utiliser la méthode println () lors de l’insertion de données dynamiques dans le fichier HTML.

La syntaxe est la suivante:

<%= expression %>

Le signe & # 39; = & # 39; doit être collé sous le signe%.

stop "height =" 42 "width =" 42 Attention: ne mettez pas & # 39; & # 39; & # 39; & # 39; à la fin de l'expression.

Exemple: insertion de la date dans la page HTML
<%@ page import="java.util.*" %>


Test de page JSP


Date d'aujourd'hui: <%= new Date() %>

Résultat:
Date du jour: jeu 15 fév 11:15:24 CET 2001

L'expression est évaluée et convertie en une chaîne avec un appel à la méthode toString (). Cette chaîne est insérée dans la page HTML à la place de la balise. Il est possible que le résultat corresponde à une partie ou à la totalité d'une balise HTML ou même à une JSP

Exemple:


Test de page JSP





<% = "

"%> Bonjour <% ="

"%>

Résultat: code HTML généré


Test de page JSP


Bonjour

73.4.2.3. Les variables implicites

Les spécifications JSP définissent plusieurs objets utilisables dans le code, les plus utiles étant:

Objet

Classe

Rôle

en dehors

javax.servlet.jsp.JspWriter

Flux de sortie de la page HTML générée

demande

javax.servlet.http.HttpServletRequest

Contient les informations de la requête

réponse

javax.servlet.http.HttpServletResponse

Contient l'information de réponse

session

javax.servlet.http.HttpSession

Gère la session

73.4.2.4. La balise scriptlets <% ... %>

Cette balise contient du code Java nommé scriptlet.

La syntaxe est la suivante: <% code Java %>

Exemple:
<%@ page import="java.util.Date"%>


<%! Date dateDuJour; %>
<% dateDuJour = new Date();%>



Date d'aujourd'hui: <%= dateDuJour %>

Par défaut, le code inclus dans la balise est inséré dans la méthode service () du servlet généré à partir du JSP.

Cette balise ne peut contenir autre chose que du code Java: elle ne peut pas contenir par exemple des balises HTML ou JSP. Pour ce faire, vous devez fermer la balise de scriptlet, placer la balise HTML ou JSP, puis redémarrer une balise de scriptlet pour continuer le code.

Exemple:


Test de page JSP





<% pour (int i = 0; i<10; i++)  %> 
<%= i %> 
<% %>

Résultat: la page HTML générée


Test de page JSP





0 
1
2
3
4
5
6
7
8
9

73.4.3. Tags de commentaire

Il existe deux types de commentaires avec les JSP:

  • commentaires visibles dans le code HTML
  • commentaires invisibles dans le code HTML

73.4.3.1. Commentaires HTML

Ces commentaires sont ceux définis par le format HTML. Ils sont entièrement reproduits dans le fichier HTML généré. Il est possible d'insérer dans cette balise une balise JSP de type expression à exécuter.

La syntaxe est la suivante:

<! – commentaires[[[[<%= expression %> ]->

Exemple:
<%@ page import="java.util.*" %>


Test de page JSP





<! - Cette page a été générée sur <%= new Date() %> ->

Bonjour

Résultat:


Test de page JSP



Bonjour

Le contenu d'une expression incluse dans les commentaires est dynamique: sa valeur peut changer à chaque génération de la page en fonction de son contenu.

73.4.3.2. Commentaires cachés <%-- ... --%>

Les commentaires masqués sont utilisés pour documenter la page JSP. Leur contenu est ignoré par le moteur JSP et n'est donc pas reproduit dans la page HTML générée.

La syntaxe est la suivante:

<%-- commentaires --%>

Exemple:


Test de page JSP


<%-- Commentaires de la page JSP --%>

Bonjour

Résultat:


Test de page JSP


Bonjour

Cette balise peut être utile pour éviter l'exécution de code pendant la phase de débogage.

73.4.4. Les balises d'action

Les étiquettes d'action permettent d'effectuer des traitements couramment utilisés.

73.4.4.1. Le tag

Le tag vous permet de localiser une instance ou d'instancier un bean à utiliser dans le fichier JSP.

L'utilisation d'un bean dans une JSP est très pratique car elle peut encapsuler des processus complexes et être réutilisée par d'autres JSP ou composants. Par exemple, le bean peut fournir un accès à une base de données. L'utilisation de beans simplifie les processus inclus dans le JSP.

Lors de l'instanciation d'un bean, nous spécifions la portée du bean. Si le bean demandé est déjà instancié pour la portée spécifiée, aucune nouvelle instance du bean n'est créée, mais sa référence est simplement renvoyée: la balise n'instancie pas nécessairement un objet.

Cette balise ne permet pas de traiter directement EJB.

La syntaxe est la suivante:

<Jsp: useBean
id = "beanInstanceName "
scope = "page| Demande | session | application "

beanName = " <% = expression %> "type ="package.class"

/>

L'attribut id est utilisé pour donner un nom à la variable qui contiendra la référence sur le bean.

L'attribut scope permet de définir la portée sur laquelle le bean est défini et utilisable. La valeur de cet attribut détermine la manière dont la balise localise ou instancie le bean. Les valeurs possibles sont:

Valeur

Rôle

page

Le haricot peut être utilisé sur toute la page
JSP ainsi que dans les fichiers statiques inclus.
C'est la valeur par défaut.

demande le haricot est accessible pendant la durée de vie de la demande.
La méthode getAttribute () de l'objet request fournit une référence
sur le haricot.

session

le haricot est utilisable par tous les JSP qui appartiennent
à la même session que le JSP qui a instancié le bean. Le haricot est utilisable
tout au long de la session par toutes les pages qui y participent. Le JSP
qui crée le bean doit avoir l'attribut session = "true" dans sa directive
page.

application

le haricot est utilisable par tous les JSP qui appartiennent
à la même application que le JSP qui a instancié le bean. Le haricot est
instancié uniquement lors du rechargement de l'application.

L'attribut class est utilisé pour indiquer la classe du bean.

L'attribut type est utilisé pour spécifier le type de la variable qui contiendra la référence du bean. La valeur spécifiée doit être une super classe du bean ou une interface implémentée par le bean (directement ou par héritage).

L'attribut beanName est utilisé pour instancier le bean à l'aide de la méthode instanciate () de la classe Beans.

Exemple:

Dans cet exemple, une instance de MonBean est créée une fois dans la session. Dans la même session, l'appel de la balise avec le même bean et la même portée ne renverra que l'instance créée. Le haricot est donc accessible tout au long de la session.

Le tag recherche si une instance du bean existe avec le nom et la portée spécifiés. S'il n'existe pas, une instance est créée. S'il y a instanciation du haricot, alors les balises inclus dans la balise sont utilisés pour initialiser les propriétés du bean, sinon ils sont ignorés. Tags inclus entre les tags et ne sont exécutés que si le haricot est instancié.

Exemple:


Cet exemple a le même effet que le précédent avec une initialisation des propriétés du bean lors de son instanciation.

Exemple complet: TestBean.jsp


Test d'instanciation d'un haricot dans un JSP


Test d'utilisation d'un bean dans un JSP

nom initial = <%=personne.getNom() %>

<%personne.setNom("mon nom");%>

nom mis à jour = <%= personne.getNom() %>

Exemple complet: Person.java
paquet de test;
Classe publique Personne 
nom de chaîne privé;
private String prenom;

personne publique () 
this.name = "nom par défaut";
this.prenom = "nom par défaut";


public void setName (nom de chaîne) 
this.name = name;


public String getName () 
return (this.name);


public void setPenom (String name) 
this.prenom = prénom;


public String getPrenom () 
retour (this.prenom);

Selon le moteur JSP utilisé, les fichiers bean doivent être placés dans un répertoire particulier pour être accessibles par JSP.

Pour tester cette JSP avec Tomcat, vous devez compiler le bean Person dans le répertoire c: jakarta-tomcat webapps examples web-inf classes test et placer le fichier TestBean.jsp dans le répertoire c: jakarta-tomcat. répertoire webapps examples jsp test.

73.4.4.2. Le tag

Le tag vous permet de mettre à jour la valeur d'un ou plusieurs attributs d'un bean. La balise utilise la méthode setter (setXXX () où XXX est le nom de la propriété avec la première lettre en majuscule) pour mettre à jour la valeur. Le haricot doit exister via un appel à la balise .

Il existe trois façons de mettre à jour les propriétés à partir des paramètres de la requête ou avec une valeur:

  • alimente automatiquement toutes les propriétés avec les paramètres correspondants de la requête
  • nourrir automatiquement une propriété avec le paramètre de requête
    correspondant
  • fournir une propriété avec la valeur spécifiée

La syntaxe est la suivante:

<jsp: setProperty name = "beanInstanceName"

propriété = "nom de la propriété"valeur =" <% = expression%> "

/>

L'attribut name doit contenir le nom de la variable contenant la référence du bean. Cette valeur doit être identique à celle de l'attribut id de la balise utilisé pour instancier le haricot.

L'attribut property = "*" est utilisé pour alimenter automatiquement les propriétés du bean avec les paramètres correspondants contenus dans la requête. Le nom des propriétés et le nom des paramètres doivent être identiques.

Les paramètres de la requête étant toujours fournis sous forme de chaîne, une conversion est effectuée à l'aide de la méthode valueOf () du wrapper du type de propriété.

Exemple:

La propriété d'attribut = "propertyName "[param="[param="[param= »[param= »paramètreName "]permet de mettre à jour un attribut du haricot. Par défaut, l'alimentation est automatiquement effectuée avec le paramètre correspondant dans la requête. Si le nom de la propriété et le paramètre sont différents, il est nécessaire de spécifier la propriété d'attribut et l'attribut param contenant le nom du paramètre qui alimentera la propriété du bean.

Exemple:

La propriété d'attribut = "propertyName "valeur =" chaîne "alimente la propriété du bean avec une valeur particulière.

Exemple:

Il n'est pas possible d'utiliser param et value dans la même balise.

Exemple: Cet exemple est identique au précédent


Test d'instanciation d'un haricot dans un JSP


Test d'utilisation d'un bean dans un JSP

nom initial = <%= personne.getNom() %>

nom mis à jour = <%= personne.getNom() %>

Cette balise peut être utilisée entre les balises et initialiser les propriétés du haricot lors de son instanciation.

73.4.4.3. Le tag

Le tag Obtenir la valeur d'un attribut d'un haricot. La balise utilise la méthode getter (getXXX () où XXX est le nom de la propriété avec la première lettre en majuscule) pour obtenir la valeur et l'insérer dans la page HTML générée. Le haricot doit exister via un appel à la balise .

La syntaxe est la suivante:

<jsp: getProperty name = "beanInstanceName"propriété =" nom de la propriété« />

L'attribut name indique le nom du bean tel que déclaré dans la balise .

L'attribut de propriété indique le nom de la propriété dont nous voulons la valeur.

Exemple:


Test d'instanciation d'un haricot dans un JSP


Test d'utilisation d'un bean dans un JSP

nom initial =

nom mis à jour =

stop "height =" 42 "width =" 42 Attention: cette balise n'obtient pas la valeur d'une propriété indexée
ni les valeurs d'un attribut d'un EJB.

Note: avec Tomcat 3.1, utilisation de la balise sur un attribut dont la valeur est null n'affiche rien tandis que l'utilisation d'une balise d'expression renvoie "null".

Exemple:


Test d'instanciation d'un haricot dans un JSP


Test d'utilisation d'un bean dans un JSP

nom initial =

<% personne.setNom(null);%>

nom mis à jour =

nom mis à jour = <%= personne.getNom() %>

73.4.4.4. La balise de redirection

Le tag Vous permet de rediriger la demande vers une autre URL pointant vers un fichier HTML, JSP ou un fichier de servlet.

Dès que le moteur JSP rencontre cette balise, il redirige la demande vers l'URL spécifiée et ignore le reste de la JSP actuelle. Tout ce qui a été généré par le JSP est perdu.

La syntaxe est la suivante:

<jsp: forward page = "RelativeURL « />
ou
<jsp: forward page = " <% = expression %> ">
<jsp: param name = "le nom du paramètre"valeur =" <% = expression %> « /> +

L'option de page doit contenir la valeur de l'URL de la ressource vers laquelle la demande sera redirigée.

Cette URL est absolue si elle commence par un & # 39; / & # 39; sinon, il est relatif au JSP. Dans le cas d'une URL absolue, le serveur Web détermine l'emplacement de la ressource.

Il est possible de passer un ou plusieurs paramètres à la ressource appelée grâce au tag .

Exemple: Test8.jsp
 
 

Page initiale appelée

Exemple: forward.htm


Page HTML


Page HTML transférée

Dans l'exemple, le fichier forward.htm doit se trouver dans le même répertoire que le fichier JSP. Lors de l'appel de la JSP, la page HTML est affichée. Le contenu généré par la page JSP n'est pas affiché.

73.4.4.5. Le tag

Cette balise inclut de manière dynamique le contenu généré par un JSP ou un servlet au moment de l’exécution du JSP. C'est la différence avec la directive include pour laquelle le fichier est inséré dans le fichier JSP avant la génération du servlet.

La syntaxe est la suivante:

<jsp: include page = "relativeURL "flush =" true " />

L'attribut page vous permet de spécifier l'URL relative de l'élément à insérer.

L'attribut flush indique si le tampon doit être envoyé au client et vidé. Si la valeur de ce paramètre est true, il n'est pas possible d'utiliser certaines fonctionnalités du servlet ou du JSP appelé: il n'est pas possible de modifier l'en-tête de la réponse (en-tête, cookies) ni de le suivre sur une autre page.

Exemple:

  
    
    

Bonjour

Il est possible de fournir des paramètres au servlet ou au JSP appelé à l’aide de la balise .

73.4.4.6. Le tag

Cette balise permet de générer le code HTML nécessaire pour exécuter une applet en fonction du navigateur: une balise HTML ou est généré en fonction de l'attribut User-Agent de la requête.

Le tag a trois attributs requis:

Attribut Rôle
code permet de spécifier le nom de la classe
base de code contient une URL spécifiant le chemin absolu ou relatif du répertoire contenant la classe ou l'archive
type les valeurs possibles sont applet ou bean

Il possède également plusieurs autres attributs facultatifs, les plus utilisés étant:

Attribut Rôle
aligner permet de spécifier l'alignement de l'applet: les valeurs possibles sont bas, milieu ou haut
archiver permet de spécifier un ensemble de ressources (bibliothèques JAR, classes, …) à charger automatiquement. Le chemin de ces ressources prend en compte l'attribut codebase
la taille spécifie la hauteur de l'applet en pixel ou en pourcentage
hspace spécifie le nombre de pixels insérés à gauche et à droite de l'applet
reconversion spécifie la version minimale du jer à utiliser pour exécuter l'applet
prénom spécifier le nom de l'applet
vspace spécifie le nombre de pixels insérés en haut et en bas de l'applet
largeur spécifie la longueur de l'applet en pixel ou en pourcentage

To be a try out of the setting of tag, it faut utiliser in the body of tag le tag . Chaque paramètre sera alors défini dans un tag .

Exemple:

  
     
  

Le tag dans le corps du tag permet de préciser un message qui sera affiché dans les navigateurs ne supportant pas le tag HTML ou .

L'exemple de cette section est composé de deux pages.

La première page est une page HTML qui demande à être son nom et invoquant une url vers une JSP.

Exemple: TestJSPIdent.html


Identification


Entrez votre nom:

La page JSP salue l'utilisateur en récupérant son nom.

Exemple: TestJSPAccueil.jsp
 
 
Accueil
 
 
<% 
String nom = request.getParameter("nom"); 
%> 

Bonjour <%= nom %>

Lors de l'exécution d'une page JSP, des erreurs peuvent survenir. Chaque erreur est traduite par la levée d'une exception. Si cette exception est capturée dans un bloc try / catch of the JSP, celle-ci est traitée. Si l’exception n’est pas capturée dans la page, il ya deux possibilités selon qu’une page d’erreur soit associée à la page JSP ou non:

  • sans page d'erreur associée, la pile d'exécution de l'exception est affichée
  • avec une page d'erreur associée, une redirection est effectuée vers ce JSP

La définition d'une page d'erreur permet de préciser dans l'attribut errorPage de la page de directive des autres JSP de l'application. Si une exception est levée dans les traitements d'une de ces pages, le JSP va automatiquement rediriger l'utilisateur vers la page d'erreur précisée.

La valeur de l'attribut page d'erreur de la directive doit contenir l'adresse URL de la page d'erreur. Le plus simple est de définir cette page à la racine de l'application web et de faire précéder le nom de la page par un caractère & # 39; / # 39; / # 39; dans l'URL.

Exemple:
<%@ page errorPage="/mapagederreur.jsp" %>

73.6.1. La définition d'une page d'erreur

Une page d'erreur est une JSP sans l'attribut isErrorPage est égal à true dans la page de directive. Une telle page dispose d'un accès à la variable implicite nommée exception de type Jetable qui encapsule l'exception qui a été levée.

Il est possible dans une telle page d'afficher un message d'erreur personnalisée mais aussi de traiter de manière liée à la gestion de l'exception: ajouter l'exception dans un journal, envoyer un mail pour son traitement, …

Exemple:
<%@ page language="java" contentType="text/html" %>



% @ page isErrorPage = "true"%>

  
    

Une erreur est survenue lors des traitements

<%= exception.getMessage() %>

Les bibliothèques de tags (taglibs) ou les tags personnalisés (tags personnalisés) permettent de définir leurs propres balises XML, de regrouper dans une bibliothèque et de réutiliser dans des fichiers JSP. C’est une extension de la technologie JSP à partir de la version 1.1 des spécifications du JSP.

73.7.1. La présentation des tags personnalisés

Un élément personnalisé du langage JSP a été personnalisé avec JSP. Ces dernières dernières permettent de définir ses propres tags qui ont été réalisées pour générer la réponse.

Le principal, mais est de préférer la séparation des rôles entre le développeur Java et le concepteur de pages web. L'idée maîtresse est de déformer le code Java contenu dans les scriplets de la classe JSP dans les classes dédiées et l'appelant dans le code source de la classe JSP.

Ce concept peut sembler proche de celui des javabeans. Les javabeans sont particulièrement adaptés pour stocker et échanger des données entre les composants de l&#39;application web en passant par la session.

Les tags personnalisés sont adaptés pour enlever du code Java inclus dans les JSP et le déporter dans une classe dédiée. Cette classe est physiquement un javabean qui implémente une interface particulière.

La principale différence entre un javabean et un tag personnalisé est que ce dernier tient compte de l&#39;environnement dans lequel il s&#39;exécute (notamment la JSP et le contexte de l&#39;application web ) et interagit avec lui.

Pour de plus amples informations sur les bibliothèques de tags personnalisés, il suffit de consulter le site qui leur est consacré :
http://www.oracle.com/technetwork/java/index-jsp-135995.html.

Les tags personnalisés possèdent des fonctionnalités intéressantes :

  • ils ont un accès aux objets de la JSP notamment l&#39;objet de type HttpResponse. Ils peuvent donc modifier le contenu de la réponse générée par la JSP
  • ils peuvent recevoir des paramètres envoyés à partir de la JSP qui les appelle
  • ils peuvent avoir un corps qu&#39;ils peuvent manipuler. Par extension de cette fonctionnalité, il est possible d&#39;imbriquer un tag personnalisé dans un autre avec un nombre d&#39;imbrications illimité

Les avantages des bibliothèques de tags personnalisés sont :

  • une suppression du code Java dans la JSP remplacé par un tag XML facilement compréhensible ce qui simplifie grandement la JSP
  • une API facile à mettre en oeuvre
  • une forte et facile réutilisabilité des tags développés
  • une maintenance des JSP facilitée

La définition d&#39;une bibliothèque de tags comprend plusieurs entités :

  • une classe dite "handler" pour chaque tag qui compose la bibliothèque
  • un fichier de description de la bibliothèque

73.7.2. Les handlers de tags

Chaque tag est associé à une classe qui va contenir les traitements à exécuter lors de l&#39;utilisation du tag. Une telle classe est nommée "handler de tag" (tag handler). Pour permettre son appel, une telle classe doit obligatoirement implémenter directement ou indirectement l&#39;interface javax.servlet.jsp.tagext.Tag

L&#39;interface Tag possède une interface fille BodyTag qui doit être utilisée dans le cas où le corps du tag est utilisé.

Pour plus de facilité, l&#39;API JSP propose les classes TagSupport et BodyTagSupport qui implémentent respectivement l&#39;interface Tag et BodyTag. Ces deux classes, contenues dans le package javax.servlet.jsp.tagext, proposent des implémentations par défaut des méthodes de l&#39;interface. Ces deux classes proposent un traitement standard par défaut pour chacune des méthodes de l&#39;interface qu&#39;elles implémentent. Pour définir un handler de tag, il suffit d&#39;hériter de l&#39;une ou l&#39;autre de ces deux classes.

Les méthodes définies dans les interfaces Tag et BodyTag sont appelées, par la servlet issue de la compilation de la JSP, au cours de l&#39;utilisation du tag.

Le cycle de vie général d&#39;un tag est le suivant :

  • lors de la rencontre du début du tag, un objet du type du handler est instancié
  • plusieurs propriétés sont initialisées (pageContext, parent, …) en utilisant les setters correspondants
  • si le tag contient des attributs, les setters correspondants sont appelés pour alimenter leurs valeurs
  • la méthode doStartTag() est appelée
  • si la méthode doStartTag() renvoie la valeur EVAL_BODYINCLUDE alors le contenu du corps du tag est évalué
  • lors de la rencontre de la fin du tag, appel de la méthode doEndTag()
  • si la méthode doEndTag() renvoie la valeur EVAL_PAGE alors l&#39;évaluation de la page se poursuit, si elle renvoie la valeur SKIP_PAGE elle ne se poursuit pas

Toutes ces opérations sont réalisées par le code généré lors de la compilation de la JSP.

Un handler de tag possède un objet qui permet d&#39;avoir un accès aux objets implicites de la JSP. Cet objet est du type javax.servlet.jsp.PageContext

Comme le code contenu dans la classe du tag ne peut être utilisé que dans le contexte particulier du tag, il peut être intéressant de sortir une partie de ce code dans une ou plusieurs classes dédiées qui peuvent être éventuellement des beans.

Pour compiler ces classes, il faut obligatoirement que le jar de l&#39;API servlets (servlets.jar) soit inclus dans la variable CLASSPATH.

73.7.3. L&#39;interface Tag

Cette interface définit les méthodes principales pour la gestion du cycle de vie d&#39;un tag personnalisé qui ne doit pas manipuler le contenu de son corps.

Elle définit plusieurs constantes :

Constante Rôle
EVAL_BODY_INCLUDE Continuer avec l&#39;évaluation du corps du tag
EVAL_PAGE Continuer l&#39;évaluation de la page
SKIP_BODY Empêcher l&#39;évaluation du corps du tag
SKIP_PAGE Empêcher l&#39;évaluation du reste de la page

Elle définit aussi plusieurs méthodes :

Méthode Rôle
int doEndTag() Traitements à la rencontre du tag de fin
int doStartTag() Traitements à la rencontre du tag de début
setPageContext(Context) Sauvegarde du contexte de la page

La méthode doStartTag() est appelée lors de la rencontre du tag d&#39;ouverture et contient les traitements à effectuer dans ce cas. Elle doit renvoyer un entier prédéfini qui indique comment va se poursuivre le traitement du tag :

  • EVAL_BODY_INCLUDE : poursuite du traitement avec évaluation du corps du tag
  • SKIP_BODY : poursuite du traitement sans évaluation du corps du tag

La méthode doEndTag() est appelée lors de la rencontre du tag de fermeture et contient les traitements à effectuer dans ce cas. Elle doit renvoyer un entier prédéfini qui indique comment va se poursuivre le traitement de la JSP.

  • EVAL_PAGE : poursuite du traitement de la JSP
  • SKIP_PAGE : ne pas poursuivre le traitement du reste de la JSP

73.7.4. L&#39;accès aux variables implicites de la JSP

Les tags ont accès aux variables implicites de la JSP dans laquelle ils s&#39;exécutent grâce à un objet de type PageContext. La variable pageContext est un objet de ce type qui est initialisé juste après l&#39;instanciation du handler.

Le classe PageContext est une classe abstraite dont l&#39;implémentation des spécifications doit fournir une adaptation concrète.

Cette classe définit plusieurs méthodes :

Méthodes Rôles
JspWriter getOut() Permet un accès à la variable out de la JSP
Exception getException() Permet un accès à la variable exception de la JSP
Object getPage() Permet un accès à la variable page de la JSP
ServletRequest getRequest() Permet un accès à la variable request de la JSP
ServletResponse getResponse() Permet un accès à la variable response de la JSP
ServletConfig getServletConfig() Permet un accès à l&#39;instance de la variable de type ServletConfig
ServletContext getServletContext() Permet un accès à l&#39;instance de la variable de type ServletContext
HttpSession getSession() Permet un accès à la session
Object getAttribute(String) Renvoie l&#39;objet associé au nom fourni en paramètre dans la portée de la page
setAttribute(String, Object) Permet de placer dans la portée de la page un objet dont le nom est fourni en paramètre

73.7.5. Les deux types de handlers

Il existe deux types de handlers :

  • les handlers de tags sans corps
  • les handlers de tags avec corps

73.7.5.1. Les handlers de tags sans corps

Pour définir le handler d&#39;un tag personnalisé sans corps, il suffit de définir une classe qui implémente l&#39;interface Tag ou qui héritent de la classe TagSupport. Il faut définir ou redéfinir les méthodes doStartTag() et endStartTag().

La méthode doStartTag() est appelée à la rencontre du début du tag. Cette méthode doit contenir le code à exécuter dans ce cas et renvoyer la constante SKIP_BODY puisque le tag ne contient pas de corps.

73.7.5.2. Les handlers de tags avec corps

Le cycle de vie d&#39;un tel tag inclut le traitement du corps si la méthode doStartTag() renvoie la valeur EVAL_BODY_TAG.

Dans ce cas, les opérations suivantes sont réalisées :

  • la méthode setBodyContent() est appelée
  • le contenu du corps est traité
  • la méthode doAfterBody() est appelée. Si elle renvoie la valeur EVAL_BODY_TAG, le contenu du corps est de nouveau traité

73.7.6. Les paramètres d&#39;un tag

Un tag peut avoir un ou plusieurs paramètres qui seront transmis à la classe par des attributs. Pour chacun des paramètres, il faut définir des getters et des setters en respectant les règles et conventions des Java beans. Il est impératif de définir un champ, un setter et éventuellement un accesseur pour chaque attribut.

La JSP utilisera le setter pour fournir à l&#39;objet la valeur de l&#39;attribut.

Au moment de la génération de la servlet par le moteur de JSP, celui-ci vérifie par introspection la présence d&#39;un setter pour l&#39;attribut concerné.

73.7.7. La définition du fichier de description de la bibliothèque de tags (TLD)

Le fichier de description de la bibliothèque de tags (tag library descriptor file) est un fichier au format XML qui décrit une bibliothèque de tags. Les informations qu&#39;il contient concernent la bibliothèque de tags elle-même et aussi chacun des tags qui la compose.

Ce fichier est utilisé par le conteneur Web lors de la compilation de la JSP pour remplacer le tag par du code Java.

Ce fichier doit toujours avoir pour extension .tld. Il doit être placé dans le répertoire web-inf du fichier war ou dans un de ses sous-répertoires. Le plus pratique est de tous les regrouper dans un répertoire nommé par exemple tags ou tld.

Comme tout bon fichier XML, le fichier TLD commence par un prologue :

Exemple :

La DTD précisée doit correspondre à la version de l&#39;API JSP utilisée. L&#39;exemple précédent concernait la version 1.1, l&#39;exemple suivant concerne la version 1.2

Exemple :

Le tag racine du document XML est le tag .

Ce tag peut contenir plusieurs tags qui définissent les caractéristiques générales de la bibliothèque. Les tags suivants  sont définis dans les spécifications 1.2 :

prénom Rôle
tlib-version version de la bibliothèque
jsp-version version des spécifications JSP utilisées
short-name nom court de la bibliothèque (optionnel)
uri URI qui identifie de façon unique la bibliothèque : cette URI n&#39;a pas besoin d&#39;exister réellement
display-name nom de la bibliothèque
small-icon (optionnel)
large-icon (optionnel)
la description description de la bibliothèque
validateur (optionnel)
auditeur (optionnel)
étiquette il en faut autant que de tags qui composent la bibliothèque

Pour chaque tag personnalisé défini dans la bibliothèque, il faut un tag . Ce tag permet de définir les caractéristiques d&#39;un tag de la bibliothèque.

Ce tag peut contenir les tags suivants :

prénom Rôle
prénom nom du tag : il doit être unique dans la bibliothèque
tag-class nom entièrement qualifié de la classe qui contient le handler du tag
tei-class nom qualifié d&#39;une classe fille de la classe javax.servlet.jsp.tagext.TagExtraInfo (optionnel)
body-content type du corps du tag. Les valeurs possibles sont :

  • JSP : le corps du tag contient des tags JSP qui doivent être interprétés
  • tagdependent : l&#39;interprétation du contenu du corps est faite par le tag
  • empty : le corps doit obligatoirement être vide

La valeur par défaut est JSP

display-name nom court du tag
small-icon nom relatif à la bibliothèque d&#39;un fichier gif ou jpeg contenant une icône. (optionnel)
large-icon nom relatif à la bibliothèque d&#39;un fichier gif ou jpeg contenant une icône. (optionnel)
la description description du tag (optionnel)
variable (optionnel)
attribut il en faut autant que d&#39;attributs possédés par le tag (optionnel)
Exemple un exemple de l&#39;utilisation du tag (optionnel)

Pour chaque attribut du tag personnalisé, il faut utiliser un tag . Ce tag décrit un attribut d&#39;un tag et peut contenir les tags suivants :

prénom La description
prénom nom de l&#39;attribut
Champs obligatoires booléen qui indique la présence obligatoire de l&#39;attribut
rtexprvalue booléen qui indique si la page doit évaluer l&#39;expression lors de l&#39;exécution. Il faut donc mettre la valeur true si la valeur de l&#39;attribut est fournie avec un tag JSP d&#39;expression <%= %>

Le tag contient les tags suivants :

prénom Rôle
name-given
name-from-attribut
variable-class nom de la classe de la valeur de l&#39;attribut. Par défaut java.lang.String
déclarer par défaut : True
portée visibilité de l&#39;attribut. Les valeurs possibles sont :

      Par défaut : NESTED (optionnel)

la description description de l&#39;attribut (optionnel)

Chaque bibliothèque doit être définie avec un fichier de description au format xml possédant une extension .tld. Le contenu de ce fichier doit pouvoir être validé avec une DTD fournie par Sun.

Ce fichier est habituellement stocké dans le répertoire web-inf de l&#39;application web ou un de ses sous-répertoires.

Exemple :

  

  1,0
  1.1
  testtaglib
  http://perso.jmd.test.taglib
  Bibliotheque de test des taglibs

  
  testtaglib1
  perso.jmd.test.taglib.TestTaglib1
  Tag qui affiche bonjour
  

73.7.8. L&#39;utilisation d&#39;une bibliothèque de tags

Pour utiliser une bibliothèque de tags, il y a des actions à réaliser au niveau du code source de la JSP et au niveau de conteneur d&#39;applications web pour la déployer.

73.7.8.1. L&#39;utilisation dans le code source d&#39;une JSP

Chaque bibliothèque utilisée dans une JSP doit être déclarée avant son utilisation en utilisant la directive taglib. Le plus simple est d&#39;effectuer ces déclarations tout au début du code de la JSP.

Cette directive possède deux attributs :

Dans ce dernier cas, il faut ajouter pour chaque bibliothèque un tag dans le fichier de description de déploiement de l&#39;application/WEB-INF/web.xml

Exemple :
  
    /maTagLibTest
    /WEB-INF/tld/testtaglib.tld
  

L&#39;appel d&#39;un tag se fait en utilisant un tag dont le nom a la forme suivante : prefix:tag

Le préfix est celui défini dans la directive taglib.

Exemple : un tag sans corps

Exemple : un tag avec corps

   
   
   
   ...

Le corps peut contenir du code HTML, du code JSP ou d&#39;autre tag personnalisé.

Le tag peut avoir des attributs si ceux-ci ont été définis. La syntaxe pour les utiliser respecte la norme XML.

Exemple : un tag avec un paramètre constant

La valeur de cet attribut peut être une donnée dynamiquement évaluée lors de l&#39;exécution :

Exemple : un tag avec un paramètre
<prefix:tag attribut="<%= uneVariable%>"/>

73.7.8.2. Le déploiement d&#39;une bibliothèque

Au moment de la compilation de la JSP en servlet, le conteneur transforme chaque tag en un appel à un objet du type de la classe associée au tag.

Il y a deux types d&#39;éléments auxquels le conteneur d&#39;applications web doit pouvoir accéder :

  • le fichier de description de la bibliothèque
  • les classes des handlers de tags

Les classes des handlers de tags peuvent être stockées à deux endroits dans le fichier war selon leur format :

  • s&#39;ils sont packagés sous forme de fichiers jar alors ils doivent être placés dans le répertoire /WEB-INF/lib
  • s&#39;ils ne sont pas packagés alors ils doivent être placés dans le répertoire /WEB-INF/classes

73.7.9. Le déploiement et les tests dans Tomcat

Tomcat étant l&#39;implémentation de référence pour les technologies servlets et JSP, il est pratique d&#39;effectuer des tests avec cet outil.

La version de Tomcat utilisée dans cette section est la 3.2.1.

Le déploiement se fait en deux étapes :

  • la copie des fichiers
  • l&#39;enregistrement de la bibliothèque

Les classes compilées doivent être copiées dans le répertoire WEB-INF/classes de la webapp si elles ne sont pas packagées dans une archive jar, sinon le ou les fichiers .jar doivent être copiés dans le répertoire WEB-INF/lib.

Le fichier .tld doit être copié dans le répertoire WEB-INF ou dans un de ses sous-répertoires.

Il faut ensuite enregistrer la bibliothèque dans le fichier de configuration web.xml contenu dans le répertoire web-inf du répertoire de l&#39;application web.

Il faut ajouter dans ce fichier, un tag pour chaque bibliothèque utilisée par l&#39;application web. Ce tag contient deux informations :

  • l&#39;URI de la bibliothèque contenue dans le tag taglib-uri. Cette URI doit être identique à celle définie dans le fichier de description de la bibliothèque
  • la localisation du fichier de description

Exemple :



  
    index.htm
    index.jsp
  
	
  
    /maTagLibTest
    /WEB-INF/tld/testtaglib.tld
  

Il ne reste plus qu&#39;à lancer Tomcat si ce n&#39;est pas encore fait et à saisir l&#39;url de la page contenant l&#39;appel au tag personnalisé.

73.7.10. Les bibliothèques de tags existantes

Il existe de nombreuses bibliothèques de tags libres ou commerciales disponibles sur le marché. Cette section va tenter de présenter quelques-unes des plus connues et des plus utilisées du monde libre. Cette liste n&#39;est pas exhaustive.

73.7.10.1. Struts

Struts est un framework pour la réalisation d&#39;applications web reposant sur le modèle MVC 2.

Pour la partie vue, Struts utilise les JSP et propose en plus plusieurs bibliothèques de tags pour faciliter le développement de cette partie présentation. Struts possède quatre grandes bibliothèques :

  • formulaire HMTL
  • modèles (templates)
  • Javabeans (bean)
  • traitements logiques (logic)

Le site web de Struts se trouve à l&#39;url : http://struts.apache.org/index.html.

Ce framework est détaillée dans le chapitre «Struts».

73.7.10.2. JSP Standard Tag Library (JSTL)

JSP Standard Tag Library (JSTL) est une spécification issue du travail du JCP sous la JSR numéro 52. Le chapitre «JSTL (Java server page Standard Tag Library)» fournit plus de détails sur cette spécification.

73.7.10.3. Apache Taglibs (Jakarta Taglibs)

Apache Taglibs est un ensemble de taglibs : la plupart a été déclarée deprecated notamment à cause de la standardisation de la JSTL.

Il propose en particulier, la bibliothèque Apache Standard Tag Library qui est une implémentation des versions 1.0, 1.1 et 1.2 de la spécification JSTL.

Le site officiel est à l&#39;url : http://tomcat.apache.org/taglibs/

Click to rate this post!
[Total: 0 Average: 0]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.

×