cours-et-td-NTIERS-Réparé.docx

REPUBLIQUE TUNISIENNE MINISTERE DE L’ENSEIGNEMENT SUPERIEUR, DE LA RECHERCHE SCIENTIFIQUE ET DES TECHNOLOGIES DE L'INFORMATION ET DE LA COMMUNICATION

DIRECTION GENERALE DES ETUDES TECHNOLOGIQUES INSTITUT SUPERIEUR DES ETUDES TECHNOLOGIQUES DE KASSERINE

SUPPORT DE COURS & TRAVAUX DIRIGES Programmation N-TIERS Adressé aux étudiants en troisième année de Licence Appliquée en Technologies de l’Informatique Parcours Multimédia et Développement Web

Elaboré par : Fatma zahra BOUZIDI

Assistante technologue

Contact : [email protected]

Année Universitaire 2013/2014

Avant-propos Cet ouvrage « PROGRAMMATION

N-TIERS

» est à l’intention des étudiants

de troisième année en Licence appliquée en technologies de l’informatique à l’Institut Supérieur des Etudes Technologique de Kasserine, parcours Multimédia et Développement Web . L’étudiant trouvera dans cet ouvrage une initiation à la programmation Ntiers en prenant comme exemple la plateforme JavaEE, il s’agit

de

préparer l’étudiant à apprendre les compétences théoriques nécessaires pour programmer une application

faisant la distinction entre la

présentation, le traitement et les données en imbriquant quelques API de javaEE . Après avoir compris les différentes architectures et la plateforme JavaEE, l’étudiant sera capable à la fin de cet ouvrage de créer une application simple selon le modèle MVC et de s’approfondir sur la programmation NTiers. Ce cours nécessite des prérequis: des notions en développement Java et des notions en langages HTML sont nécessaires. L’ouvrage est divisé en cinq chapitres : Le premier chapitre décrit les niveaux d’abstraction d’une application. Le découpage de ces niveaux en couches définit son architecture. Ce chapitre présente rapidement différent architectures applicatifs ainsi que leurs inconvénients et avantages. Le deuxième chapitre présente la plateforme JavaEE, ses API, son architecture, et son environnement d’exécution : l’étudiant sera capable

de distinguer entre les différentes couches d’une architecture JavaEE et les API qui les composent ainsi que le mode d’assemblage et de déploiement de chaque module d’une application JavaEE. Le troisième chapitre introduit les API Servlet et JSP en présentant les concepts nécessaires pour comprendre chaque composant : définition, radiographie, cycle de vie. Le quatrième chapitre représente le noyeau de ce cours en décrivant une implémentation simple d’une architecture MVC imbriquant les API servlet, Jsp et un objet Java : l’étudiant sera capable de collaborer entre une servlet et une Jsp, de savoir transmettre des données issues d’un client et des

données

issus

d’un

serveur

et

de

comprendre

un

exemple

implémentant le modèle MVC. Le

dernier chapitre

introduit l’API

javaBean et

présente une

implémentation de modèle MVC imbriquant les composants JSP, Servlet et javaBean.

Domaine de Formation : Sciences et Technologies

Mention TI

Mention : Technologies de l’Informatique (TI)

Spécialité MDW

Parcours : Multimédia et Développement Web

Semestre S5

UNITÉ D’ENSEIGNEMENT (UE) : PROGRAMMATION N-

Crédits : 5

Coef : 5

TIERS

Volume Horaire par Semestre : 90

Semaine : 6

Fiche Matière Élément Constitutif (ECUE)

PROGRAMMATION N-TIERS Ventilation / Semaine

Vol. Horaire / Semestre Cours 11.2 5 0.75

TD 11.2 22.5 5 0.75 1.5

Coeffici ent

Crédit s

TP 0 0

1.5

1.5

Évaluati on

Contrôle continu

Objectif(s) Génér(al)/(aux) Le cours vise à donner à l’apprenant les compétences théoriques nécessaires pour programmer des applications faisant la distinction entre l'aspect métier et les aspects non fonctionnels.

Objectifs Spécifiques - Comprendre l’architecture client serveur. - Comprendre l'architecture N-Tiers: Tiers présentation, tiers métier, tiers données. -Comprendre l’architecture MVC - Comprendre La plate-forme Java: J2EE -savoir programmer des servlets -savoir programmaer des jsps -savoir programmer des javabeans -Etre capable de mettre en œuvre une architecture MVC

Mots-Clés Client, Serveur, Métier, Plate-forme, Architecture, J2EE, MVC, N-Tiers, JSP, Servlet, JavaBean etc.

Pré-requis UE : Développement Web 1.

Éléments de Contenu

-

Architecture Client Serveur. Architecture N-Tiers. Architecture MVC Plate-forme J2EE JSP,Servlet,JavaBean Implémentation de MVC

Moyens et Outils Pédagogiques -

Cours, Travaux dirigés, mini-projet

Table des matières Chapitre I Présentation générale............................................................................. 1 1

Les trois niveaux d'abstraction d'une application.........................................2

2

L'architecture 1-tiers..................................................................................... 2

3

4

5

6

2.1

Présentation........................................................................................... 2

2.2

Limitations.............................................................................................. 3

L'architecture 2-tiers..................................................................................... 4 3.1

Présentation........................................................................................... 4

3.2

Avantages et inconvénients de l'architecture 2-tiers.............................4

L'architecture 3-tiers..................................................................................... 5 4.1

Présentation........................................................................................... 5

4.2

Avantages et inconvénients de l'architecture 3-tiers..............................6

Les architectures N-tiers...............................................................................7 5.1

Présentation........................................................................................... 7

5.2

Avantages et inconvénients de l'architecture N-tiers :..........................8

L’architecture Modèle-Vue- Contrôleur (MVC) :............................................8 6.1

Présentation........................................................................................... 8

6.2

Avantages et inconvénients..................................................................10

6.3

Différence avec l’architecture 3-tiers....................................................10

Chapitre II Présentation de la plateforme Java EE...............................................12 1

La présentation de Java EE.........................................................................13

2

Les API de Java EE....................................................................................... 13

3

Architectures en Java EE............................................................................. 14 3.1

Les composants clients ou tiers Client..................................................15

3.2

Les composants Web ou tiers Web.......................................................17

3.3

Les composants métier ou tiers Métier.................................................17

3.4

Enterprise Information System Tier......................................................18

4

Les conteneurs Java EE............................................................................... 18

5

L'assemblage et le déploiement d'applications J2EE...................................20

Chapitre III Introduction aux Servlets et pages JSP..............................................22 1

Introduction aux Servlets............................................................................23 1.1

Qu’est-ce qu'une servlet.......................................................................23

2

1.2

Cycle de vie d’une servlet....................................................................23

1.3

Radiographie d’une première servlet....................................................27

Introduction aux JSP.................................................................................... 30 2.1

Pourquoi une JSP?.................................................................................30

2.2

C’est quoi une JSP?...............................................................................30

2.3

Cycle de vie d'une JSP..........................................................................31

2.4

Radiographie d’un Script JSP................................................................33

2.5

Les Balises JSP...................................................................................... 35

2.6

Les variables prédéfinis :......................................................................39

Chapitre IV Implémentation de MVC....................................................................40 1

MVC et Java EE............................................................................................ 41

2

Collaboration entre JSP et servlets : l’interface requestdispatcher.............41

3

Transmission de données: les paramètres et les attributs..........................43

4

3.1

Différence entre paramètres et attributs..............................................43

3.2

Transmission des attributs : méthodes setAttribute() et getAttribute() 44

3.3

Transmission des paramètres : méthode getParameter().....................45

Exemples d’applications du design pattern MVC :.....................................46 4.1

Exemple1 :............................................................................................ 46

4.2

Exemple 2 :........................................................................................... 55

Chapitre V JavaBeans et Scope...........................................................................60 1

JavaBeans................................................................................................... 61 1.1

C’est quoi un Javabean.........................................................................61

1.2

Structure d’un Javabean.......................................................................61

1.3

Comment utiliser des beans ?..............................................................61

2

Implémentation du MVC (avec les JavaBeans)............................................62

3

Les Scopes d’un bean................................................................................. 66 3.1

Partage de données sur requête...........................................................66

3.2

Partage de données sur session...........................................................67

3.3

Partage de données sur application (Rare)...........................................68

Travaux dirigées................................................................................................... 70 TD N°1 : Les bases................................................................................................. 71 Correction TD N°1 : Les bases..................................................................................73 TD N°2 : Introduction aux Servlets et pages JSP.............................................................79 Correction TD N°2 : Introduction aux Servlets et pages JSP...............................................81 TD N°3: Implémentation de MVC..............................................................................95 Correction TDN°3 : Implémentation de MVC..............................................................100

DEVOIR SURVEILLE............................................................................................. 109 EXAMEN.................................................................................................................. 1 REFERENCES.......................................................................................................... 1

Liste des figures Figure I-1 : Schéma explicatif du modèle MVC.....................................................11 Figure II-1 Architecture Java EE standard..............................................................17 Figure II-2 : Tier client, Tier web et Tier métier.....................................................18 Figure II-3 : Tiers Web et Tiers Métier Java EE.......................................................20 Figure II-4 : Serveur Java EE et conteneurs...........................................................21 Figure III-1 : L’interface Servlet............................................................................. 26 Figure III-2 : cycle de vie d’une Servlet.................................................................27 Figure III-3 : cycle de vie détaillé d’une servlet....................................................29 Figure III-4 : traitement de deux requêtes par le serveur.....................................30 Figure III-5 : recherche de la Ssevlet dans le fichier web.xml...............................33 Figure III-6 : CorrespondanceJSP/Servlet...............................................................34 Figure III-7 : Cycle de vie d’une JSP......................................................................36 Figure IV-1 : Collaboration entre JSP et servlets...................................................45 Figure IV-2 : Liste des promos.............................................................................. 51 Figure IV-3 : Étape 1 du modèle MVC...................................................................51 Figure IV-4 : Étape 2 du modèle MVC...................................................................53 Figure IV-5 : Étape 3 du modèle MVC...................................................................54 Figure IV-6 : Étape 4 du modèle MVC...................................................................56 Figure IV-7 : Étape 5 du modèle MVC..................................................................57 Figure IV-8 : Liste des promos.............................................................................. 58 Figure IV-9 : Formulaire HTML............................................................................... 59 Figure IV-10 : pages d'affichage des données de formulaire................................59 Figure V-1 : implémentation du MVC....................................................................67

Liste des tableaux Tableau II-1 : Les différents types d'archives........................................................23

CHAPITRE I : PRESENTATION GENERALE

Chapitre I Présentation générale OBJECTIFS

L’objectif de ce chapitre est de :    

1

Comprendre le découpage en couches d’une application ; Comprendre l’architecture Client/serveur ; Connaitre les architectures 1-Tiers, 2-Tiers, 3-Tiers et N-Tiers ; Comprendre l’architecture MVC.

Les trois niveaux d'abstraction d'une application

En général, une application informatique peut être découpée en trois niveaux d'abstraction distincts : La présentation, encore appelée IHM permet l'interaction de l'application avec l'utilisateur. Cette couche gère les saisies au clavier, à la souris et la présentation des informations à l'écran. Dans la mesure du possible, elle doit être conviviale et ergonomique. La logique applicative, les traitements, décrivant les travaux à réaliser par l'application. Ils peuvent être découpés en deux familles : Les traitements locaux, regroupant les contrôles effectués au niveau du dialogue avec l'IHM, visant essentiellement le contrôle et l'aide à la saisie, Les traitements globaux, constituant l'application elle-même. Cette couche, appelée Business Logic ou couche métier, contient les règles internes qui régissent une entreprise donnée. Les données, ou plus exactement l'accès aux données, regroupant l'ensemble des mécanismes permettant la gestion des informations stockées par l'application. 1

CHAPITRE I : PRESENTATION GENERALE

Ces trois niveaux peuvent être imbriqués ou répartis de différentes manières entre plusieurs machines physiques. Le découpage et la répartition de ces niveaux permettent de distinguer les architectures applicatives suivantes :     2

l'architecture 1-tiers ; l'architecture 2-tiers ; l'architecture 3-tiers ; les architectures n-tiers. L'architecture 1-tiers

2.1 Présentation Dans une application 1-tiers, les trois couches applicatives sont fortement liées et s'exécutent sur le même ordinateur. On ne parle pas ici d'architecture client-serveur, mais d'informatique centralisée. Dans un contexte multi-utilisateurs, on trouve les applications sur site central : les utilisateurs se connectent aux applications exécutées par le serveur central (le mainframe) à l'aide de terminaux passifs se comportant en esclaves. C'est le serveur central qui prend en charge l'intégralité des traitements, y compris l'affichage qui est simplement déporté sur des terminaux passifs.

Figure I-1 Architecture 1-tiers 2

CHAPITRE I : PRESENTATION GENERALE

2.2 Limitations Les applications sur site central souffrent d'une interface utilisateur en mode caractères et la cohabitation d'applications micro exploitant des données communes n'est pas fiable au delà d'un certain nombre d'utilisateurs. Il a donc fallu trouver une solution conciliant les avantages des deux premières : 

La fiabilité des solutions sur site central, qui gèrent les données de



façon centralisée, l'interface utilisateur moderne des applications sur micro-ordinateurs.

Pour obtenir cette synthèse, il a fallu scinder les applications en plusieurs parties distinctes et coopérantes :  

gestion centralisée des données ; gestion locale de l'interface utilisateur ;

Ainsi est né le concept du client-serveur; 3

L'architecture 2-tiers

3.1 Présentation Dans une architecture 2-tiers, encore appelée client-serveur de première génération ou client-serveur de données, le poste client se contente de déléguer la gestion des données à un service spécialisé. Ce type d'application permet de fournir à l'utilisateur une interface riche, tout en garantissant la cohérence des données, qui restent gérées de façon centralisée. La gestion des données est prise en charge par un SGBD centralisé, s'exécutant le plus souvent sur un serveur dédié. Ce dernier est interrogé en utilisant un langage de requête qui, le plus souvent, est SQL.

3

CHAPITRE I : PRESENTATION GENERALE

Figure I-2 : Architecture 2-tiers

3.2 Avantages et inconvénients de l'architecture 2-tiers Avantages L’architecture 2-tiers présente de nombreux avantages :   

elle permet l'utilisation d'une interface utilisateur riche ; elle a permis l'appropriation des applications par l'utilisateur ; elle a introduit la notion d'interopérabilité.

Inconvénients : Le client lourd L'expérience a démontré qu'il était coûteux et contraignant de vouloir faire porter l'ensemble des traitements applicatifs par le poste client. On en arrive aujourd'hui à ce que l'on appelle le client lourd, ou fat client. L'architecture client-serveur de première génération s'est heurtée à ce constat à l'heure des premiers bilans : 

on ne peut pas soulager la charge du poste client, qui supporte la



grande majorité des traitements applicatif ; le poste client est fortement sollicité, il devient de plus en plus complexe et doit être mis à jour régulièrement pour répondre aux besoins des utilisateurs ; 4

CHAPITRE I : PRESENTATION GENERALE



la relation étroite qui existe entre le programme client et l'organisation de la partie serveur complique les évolutions de cette dernière.

Pour résoudre les limitations du client-serveur 2-tiers tout en conservant ses avantages, on a cherché une architecture plus évoluée, facilitant les forts déploiements à moindre coût. La réponse est apportée par les architectures distribuées 4

L'architecture 3-tiers

4.1 Présentation Les limites de l'architecture 2-tiers proviennent en grande partie de la nature du client utilisé, la solution résiderait donc dans l'utilisation d'un poste client simple communicant avec le serveur par le biais d'un protocole standard. Dans ce but, l'architecture 3-tiers, encore appelée client-serveur de deuxième génération ou client-serveur distribué, sépare l'application en trois niveaux de service distincts : 

premier niveau : l'affichage et les traitements locaux (contrôles de saisie, mise en forme de données...) sont pris en charge par le poste



client ; deuxième niveau : les traitements applicatifs globaux sont pris en



charge par le service applicatif ; troisième niveau : les services de base de données sont pris en charge par un SGBD.

Tous ces niveaux étant indépendants, ils peuvent être implantés sur des machines différentes.

5

CHAPITRE I : PRESENTATION GENERALE

Figure I-3 : Architecture 3-tiers

4.2 Avantages et inconvénients de l'architecture 3-tiers Avantages : Le client léger Dans l'architecture 3-tiers, le poste client est communément appelé client léger ou Thin Client, par opposition au client lourd des architectures 2tiers. Il ne prend en charge que la présentation de l'application avec, éventuellement, une partie de logique applicative permettant une vérification immédiate de la saisie et la mise en forme des données. Il est souvent constitué d'un simple navigateur Internet. Le poste client ne dispose d'aucune connaissance des traitements applicatifs ou de la structure des données exploitées. Les évolutions de l'application sont donc possibles sans nécessiter de modification de la partie cliente.

Inconvénients L'architecture 3-tiers a corrigé les excès du client lourd en centralisant une grande partie de la logique applicative sur un serveur HTTP. Le poste client, qui ne prend à sa charge que la présentation et les contrôles de saisie, s'est trouvé ainsi soulagé et plus simple à gérer. Par contre, le serveur HTTP se trouve souvent fortement sollicité et il est difficile de répartir la charge entre client et serveur.

6

CHAPITRE I : PRESENTATION GENERALE

Les contraintes semblent inversées par rapport à celles rencontrées avec les architectures 2-tiers : le client est soulagé, mais le serveur est fortement sollicité. Le juste équilibrage de la charge entre client et serveur semble atteint avec la génération suivante : les architectures n-tiers. 5

Les architectures N-tiers

5.1 Présentation L'architecture N-tiers a été pensée pour pallier aux limitations des architectures 3-tiers et concevoir des applications puissantes et simples à maintenir. L'appellation N-tiers pourrait faire penser que cette architecture met en oeuvre un nombre indéterminé de niveaux d'application, alors que ces derniers sont au maximum trois (pour rappel : la couche IHM – la couche applicative – la couche d’accès aux données). En fait, l'architecture N-tiers qualifie la distribution de la couche applicative entre de multiples services et non la multiplication des couches. Les composants ‘‘métiers'' de la couche applicative sont spécialisés et indépendants. Ils communiquent entre eux et peuvent donc coopérer en étant implantés sur des machines distinctes. Ce

type

d'architecture

permet

de

distribuer

librement

la

logique

applicative, ce qui facilite la répartition de la charge entre tous les niveaux.

7

CHAPITRE I : PRESENTATION GENERALE

Figure I-4 : Architecture N-tiers

5.2 Avantages et inconvénients

de l'architecture N-

tiers : Avantages : Théoriquement, ce type d'architecture supprime tous les inconvénient s des architectures précédentes :    

Elle permet l'utilisation d'interfaces utilisateurs riches ; Elle sépare nettement tous les niveaux de l'application ; Elle offre de grandes capacités d'extension ; facilite la gestion des sessions.

Inconvénient :  6

Nécessite des ressources matérielles importantes L’architecture Modèle-Vue- Contrôleur (MVC) :

6.1 Présentation L'architecture Modèle/Vue/Contrôleur (MVC) est une façon d'organiser une application. Elle consiste à distinguer trois entités distinctes qui sont, le modèle, la vue et le contrôleur ayant chacun un rôle précis dans l'application. Dans l'architecture MVC, les rôles des trois entités sont les suivants. 8

CHAPITRE I : PRESENTATION GENERALE

La vue : Ce qu'on nomme la vue est en fait une IHM. Celle-ci est en fait ce qu'a l'utilisateur sous les yeux. La vue peut donc être : 

Une

 

C#...) ; une page web Un terminal Linux ou une console Windows...

application

graphique swing, awt, swt pour

Java

(Form pour

Le modèle : Il décrit les données manipulées par l'application .Le modèle représente le cœur de l'application : traitements des données, interactions avec la base de données, etc.. Il regroupe la gestion de ces données et est responsable de leur intégrité. Le modèle comporte des méthodes standards pour mettre à jour ces données (insertion, suppression, changement de valeur).

Le contrôleur Contrôleur: son rôle est de traiter les événements en provenance de l’interface utilisateur et les transmet au modèle pour le faire évoluer ou à la vue pour modifier son aspect visuel (pas de modification des données affichées mais des modifications de présentation (couleur de fond, affichage ou non de la légende d’un graphique, …)). Le contrôleur ‘connaît’ la (les) vues qu’il contrôle ainsi que le modèle.

Le contrôleur pourra

appeler des méthodes du modèle pour réagir à des événements (demande d’ajout d’un client par exemple), il pourra faire modifier à la vue son aspect visuel.

Il pourra aussi instancier

de nouvelles

vues (demande

d’affichage de telle ou telle info). Pour faire cela, le contrôleur sera à l'écoute d'événements survenant sur les vues.

Interactions Les différentes interactions entre le modèle, la vue et le contrôleur sont résumées par le schéma de la figure suivante.

9

CHAPITRE I : PRESENTATION GENERALE

Figure I-5 : Schéma explicatif du modèle MVC

6.2 Avantages et inconvénients Un avantage apporté par ce modèle est la clarté de l'architecture qu'il impose. Cela simplifie la tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le projet. En

effet, la

modification des traitements ne change en rien la vue. Par exemple on peut passer d'une base

de données de type SQL à XML en changeant

simplement les traitements d'interaction avec la base, et les vues ne s'en trouvent pas affectées. Le MVC montre ses limites dans le cadre des applications utilisant les technologies du web,

bâties à partir de serveurs d'applications. Des

couches supplémentaires sont alors introduites ainsi que les mécanismes de dépendance.

6.3 Diférence avec l’architecture 3-tiers L'architecture 3-tiers est un modèle en couches, c'est-à-dire, que chaque couche communique seulement avec ses couches adjacentes (supérieures 10

CHAPITRE I : PRESENTATION GENERALE

et inférieures) et

les couches supérieures contrôlent les couches

inférieures, c'est-à-dire, que les couches supérieures sont toujours sources d'interaction (clients) alors que les couches inférieures ne font que répondre à des requêtes (serveurs). Dans le modèle MVC, il est généralement admis que la vue puisse consulter directement le modèle (lecture) sans passer par le contrôleur. Par contre, elle doit nécessairement passer par le contrôleur pour effectuer une modification (écriture). Le contrôleur peut envoyer des requêtes à toutes les vues de manière à ce qu'elles se mettent à jour. Dans l'architecture 3-tiers, si une vue modifie les données, toutes les vues concernées par la modification doivent être mises à jour, d'où l'utilité de l'utilisation du MVC au niveau de la couche de présentation. De

plus,La

différence

fondamentale

se

trouve

dans

le

fait

que

l'architecture 3-tiers sépare la couche Buisness logic (couche métier) de la couche Data access (accèsaux données).Pour qu'une application MVC soit une vraie application 3-tiers il faut lui ajouter une couche d'abstraction d'accès aux données. Inversement pour qu'une application 3-tiers respecte MVC il faut lui ajouter une couche de contrôle entreUser interface et Buisness logic. Loin d'être antagonistes, ces deux pratiques se combinent et sont la fondation de la plupart des frameworks de création d'applications Web.

En résumé : Ce chapitre a présenté brièvement les architectures 1-tiers, 2-tiers, 3-tiers, N-tiers et MVC, ainsi que

leurs avantages et

inconvénients. Dans les

chapitres suivant on étudiera la distinction entre les aspects présentation, métier, et données en utilisant la technologie java EE.

11

CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE

Chapitre II

Présentation de la plateforme

Java EE OBJECTIFS L’objectif de ce chapitre est de :

 

Comprendre la plateforme java EE ; Connaître les différentes couches d’une application java EE multi-



tiers et leur distribution sur les machines ; Savoir les différents APIs de la plateforme qui composent chaque



couche ; Connaitre les différents éléments qui constituent l’environnement



d’exécution des applications java EE multi-tiers ; Connaitre le mode d’assemblage et de déploiement des applications java EE multi-tiers.

1

La présentation de Java EE

J2EE est l'acronyme de Java 2 Entreprise Edition. Cette édition proposé par Sun Microsystems, désormais Oracle Corporation,

est dédiée à la

réalisation d'applications pour entreprises. J2EE est basé sur J2SE (Java 2 Standard Edition) qui contient les API de base de Java. Depuis sa version 5, J2EE est renommé Java EE (Enterprise Edition). La plate-forme J2EE offre un environnement de développement et déploiement en langage Java pour les applications distribuées à plusieurs niveaux. Elle est composée de deux parties essentielles :

CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE



un ensemble de spécifications pour une infrastructure dans laquelle s'exécutent les composants écrits en Java : un tel environnement se



nomme serveur d'application ; un ensemble d'API qui peut être obtenu et utilisé séparément.

L'utilisation

de

J2EE

pour

développer

et

exécuter

une application

propose plusieurs avantages : 

une architecture d'application basée sur les composants qui permet un découpage de l'application et donc une séparation des rôles lors du



développement ; la possibilité de s'interfacer avec le système d'information existant



grâce à de nombreuses API : JDBC, JNDI, JMS, JCA ... la possibilité de choisir les outils de développement et le ou les serveurs d'applications utilisés qu'ils soient commerciaux ou libres

2

Les API de Java EE

Une API (Application Programming Interface) est une interface de programmation. C’est un ensemble de fonctions, procédures ou classes mises à disposition des programmes informatiques par une bibliothèque logicielle, un système d’exploitation ou un service. Les API de Java EE peuvent se répartir en trois grandes catégories : 

Les composants. On distingue habituellement deux familles de composants : o Les composants web : Servlets et JSP (Java Server Pages). Il s'agit de la partie Chargée de l'interface avec l'utilisateur (on parle de logique de présentation) ; o Les composants métier : EJB (Enterprise Java Beans). Il s'agit de composants Spécifiques chargés des traitements des données propres à un secteur d'activité (on parle de logique métier ou de logique applicative) et de l'interfaçage avec les bases de



données. Les services, pouvant être classés par catégories : o Les services d'infrastructures : il en existe un grand nombre, définis ci-dessous :

CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE

-

JDBC (Java DataBase Connectivity) est une API d'accès aux bases

-

de données relationnelles ; JNDI (Java Naming and Directory Interface) est une API d'accès aux services de nommage et aux annuaires d'entreprises tels que

-

DNS, LDAP, etc..; JTA/JTS (Java Transaction API/Java Transaction Services) est une

-

API de gestion des transactions ; J2EE Connector est une API qui facilite les connexions aux plates-

-

formes autres que J2EE ; JMX (Java Management

Extension)

fournit

des

extensions

permettant de développer des applications web de supervision d'applications. o Les services de communication : - JAAS (Java Authentication and Authorization Service) est une API -

de gestion de l'authentification et des droits d'accès ; JavaMail est une API permettant l'envoi de courrier électronique. ; JMS (Java Message Service) Permet à 2 composants d'applications

-

J2EE de créer, envoyer et recevoir des messages ; RMI-IIOP est une API permettant la communication synchrone entre objets.

3

Architectures en Java EE

J2EE permet une grande flexibilité dans le choix de l'architecture de l'application en combinant les différents composants. Ce choix dépend des besoins auxquels doit répondre l'application mais aussi des compétences dans les différentes API de J2EE. D'après le schéma ci-après, la spécification Java EE définit les composants suivants : 

Les composants Clients (ou tier Client) s'exécutent sur la machine des

 

utilisateurs ; Les composants Web(ou tiersWeb) s'exécutent sur le serveur J2EE ; Les composants métier ou ( tier Métier) s'exécutent sur le serveur Java



EE ; La partie stockage des données, nommée tiers Enterprise Information System (EIS), s'exécute sur le serveur de base de données.

CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE

Figure II-6 Architecture Java EE standard Une application Java EE multi-tiers correspond à un ensemble de couches. Elle est distribuée de manière physique sur trois machines :   

La machine des clients ; Le serveur d'applications Java EE ; Le serveur de base de données ou de stockages.

3.1 Les composants clients ou tiers Client La plate-forme Java EE propose trois types de clients : les clients Web, les Applets et les applications clientes riches type Java SE.

3.1.1 Les clients Web Un client Web consiste en des pages Web de différents types (HTML, XHTML, XML, JavaScript ou autres) générées à partir de composants exécutés côté serveur dans un conteneur Web.

CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE

Un client Web se compose de deux parties: des pages web de différents types (HTML, XML, etc) générées à partir de composants Web exécutés côté serveur, et d'un navigateur Web, ce qui permet d’afficher les pages reçues du serveur. Un client Web est parfois appelé un client léger.

3.1.2 Les clients Applets Une page Web reçu de la couche web peut inclure une applet intégrée. Une applet est une petite application cliente écrite en langage de programmation Java qui s'exécute dans la machine virtuelle Java installée dans le navigateur. Cependant cette technique est plus contraignante à maintenir, requiert des accès et des droits pour la sécurité et nécessite un plug-in pour les navigateurs. Les clients Web sont donc préférables pour la création du tiers Client.

3.1.3 Les applications clientes Une application de type client est un logiciel riche, qui s'exécute sur la machine du client et fournit un ensemble de services aux utilisateurs par l'intermédiaire

d'une

interface

graphique

évoluée

encore

appelée

Graphical User Interface (GUI). Ces applications riches sont développées avec les composants SWING en général, exécutées Application Client Container (ACC).

Figure II-7 : Tiers client, Tiers web et Tiers métier

CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE

La figure ci-dessus montre les différents types de clients utilisés dans une plate-forme Java EE. Les clients riches de type application communiquent directement avec le tiers Métier alors que les clients de type navigateur Internet communiquent à travers le tiers Web par l'intermédiaire de pages exécutées sur le serveur et générées par des Servlets, JSP ou JSF.

3.2 Les composants Web ou tiers Web Les composants Web Java EE sont des Servlets et/ou des pages web ( JavaServer Pages et/ou des JavaServer Faces). Les Servlets sont des classes Java, capables d'intercepter et de gérer les requêtes du protocole HTTP. Les pages JSP sont des documents textuels exécutés comme des Servlets apportant une solution simplifiée pour la programmation de pages Web. La technologie JavaServer Faces est construite à partir de Servlets et fournit un framework de développement pour accélérer la création d'applications Web.

3.3 Les composants métier ou tiers Métier Les composants métier ou tiers Métier représentent la couche business, avec les données du système, et sont de deux types : Les entités beans (entity bean ou bean entity) peuvent être exécutées par un conteneur léger (pas forcément un serveur Java EE) Les Enterprise JavaBeans offrent des possibilités plus riches comme la gestion des transactions, les accès directs par clients riches ou encore la gestion automatique des sessions utilisateur, mais sont exécutés sur un conteneur lourd, c'est-à-dire compatible Java EE.

CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE

Figure II-8 : Tiers Web et Tiers Métier Java EE

3.4 Enterprise Information System Tier La partie stockage des données, nommée Enterprise Information System (EIS) Tier est directement liée au tiers Métier et correspond dans la majorité des cas, aux systèmes de gestion de bases de données (Derby, MySQL, PostgreSQL, Oracle ou autres) ou n'importe quel système de stockage évolué. 4

Les conteneurs Java EE

Les serveurs Java EE proposent plusieurs types de conteneurs (containers) pour chaque type de composant. Chaque conteneur a un rôle bien défini et offre un ensemble de services pour les développeurs. Les conteneurs assurent la gestion du cycle de vie des composants qui s'exécutent en eux et fournissent des services qui peuvent être utilisés par les applications lors de leur exécution.

CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE

Une application Java EE de type Web nécessite un conteneur Web pour son exécution alors qu’une application utilisant les EJB nécessite un conteneur EJB pour son exécution. Chaque conteneur propose un ensemble de services avec ses avantages et ses contraintes. Les serveurs d’applications peuvent fournir un conteneur web uniquement (exemple : Tomcat) ou un conteneur d'EJB uniquement (exemple : JBoss, Jonas, ...) ou les deux (exemple : Websphere, Weblogic, ...).

Figure II-9 : Serveur Java EE et conteneurs Le serveur Java EE est composé de deux types de conteneurs : 

Web Container ou conteneur Web, capable d’exécuter des pages JSP, Servlets et programmes JSF (implémentation JSF nécessaire). Ces composants s’exécutent avec le conteneur serveur Java EE. Ce conteneur supporte les protocoles HTTP et HTTPS et dialogue avec différents types de clients (navigateur, application) ;

CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE



EJB Container ou conteneur EJB, responsable de la couche métier et de l’exécution des EJB. Ce conteneur fournit le mécanisme de gestion des EJB et la gestion de leur cycle de vie ;

5

L'assemblage et le déploiement d'applications J2EE

Pour déployer une application dans un conteneur, il faut lui fournir deux éléments : 

l'application

avec

tous

les

composants

(classes

compilées,

ressources ...) regroupée dans une archive ou module. Chaque 

conteneur possède son propre format d'archive. un fichier descripteur de déploiement contenu dans le module qui précise au conteneur des options pour exécuter l'application

Il existe différents types d'archives : Descript Archive

/

module

Contenu

Extensi eur on

de

déploie ment

application client

Regroupe les ressources nécessaires à

applicatio

leur exécution (classes, bibliothèques, jar

n-

images, ...)

client.xml

Regroupe les servlets et les JSP ainsi Web

que les ressources nécessaires à leur exécution (classes, bibliothèques de

war

web.xml

balises, images, ...) EJB

Regroupe les EJB et leurs composants (classes)

jar

ejbjar.xml

Tableau II-1 : Les diférents types d'archives

Une application J2EE peut regrouper différents modules : modules web,

CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE

modules EJB ... Chacun de ces modules possède son propre mode de packaging. J2EE propose de regrouper ces différents modules dans un module unique sous la forme d'un fichier EAR (Entreprise Archive). Le format de cette archive est très semblable à celui des autres archives : 

un contenu : les différents modules qui composent l'application



(module web, EJB, fichier RAR, ...) ; un fichier descripteur de déploiement nommé application.xml.

En résumé Ce chapitre a donné un aperçu sur la plateforme JavaEE et les différentes API qui la composent, il a décrit les différents éléments qui composent l'environnement d'exécution des applications JavaEE et leurs modes d'assemblage et de déploiement. Dans le chapitre qui suit nous allons découvrir les servlets et les jsp qui seront utilisés pour implémenter le modèle MVC.

Chapitre III : Introduction aux Servlets et pages JSP

Chapitre III

Introduction aux Servlets et

pages JSP OBJECTIFS L’objectif de ce chapitre est de :

    1

Comprendre le cycle de vie d’une servlet ; Savoir programmer une servlet ; Comprendre le cycle de vie d’une jsp ; Savoir programmer une jsp.

Introduction aux Servlets

1.1 Qu’est-ce qu'une servlet Une Servlet est un composant web conçu sous la forme d’une classe java qui existe au sein d’une application web et dont la mise en œuvre est géré par un conteneur web (exemple Tomcat ). une Servlet interagit avec un client web par l’intermédiaire du protocole http, via un mécanisme de requête/réponse. Une servlet s'exécute dynamiquement sur le serveur web et permet l'extension des fonctions de ce dernier. Typiquement : accès à des bases de données, transactions d'e-commerce, etc. Une servlet peut être chargée automatiquement lors du démarrage du serveur web ou lors de la première requête du client. Une fois chargées, les servlets restent actives dans l'attente d'autres requêtes du client.

1.2 Cycle de vie d’une servlet Une servlet est un objet qui peut être manipulé par le conteneur via l’interface suivante:

Chapitre III : Introduction aux Servlets et pages JSP

Figure III-10 : L’interface Servlet Lorsque le conteneur reçoit une requête, il la transmet au servlet qui correspond à l’URL pour que la requête soit traitée effectivement. Le cycles de vie d’une servlet se résume comme suit : 1. Chargement de la classe 2. Instanciation du servlet (constructeur par défaut) 3. Appel de init() 4. Appel(s) de service()(1 thread par requête) 5. Appel de destroy()

Chapitre III : Introduction aux Servlets et pages JSP

Figure III-11 : cycle de vie d’une Servlet 

Les servlets ne sont pas des objets instanciés à chaque requête HTTP, Il n'existe qu'une et une seule instance d'une servlet dans le



conteneur. Ce qu'il se passe c'est que pour chaque requête HTTP, un thread est créé pour satisfaire la requête et proposer une réponse :

Si on reprend la vie de notre servlet partant du principe que la servlet est initialisée, voici ce que ça donnerait :  

La servlet reçoit une requête HTTP ; Elle crée les deux objets : o Un objet HttpServletRequest contenant les informations de la requête HTTP ; o Un objet HttpServletResponse, servant à fournir la réponse attendue.

Une fois ceci fait, il va utiliser la servlet correspondant à la requête demandée

et

va

invoquer

la

méthode

adéquate,

ici

doGet(HttpServletRequest request, HttpServletResponse response)  

Elle alloue un nouveau thread à cette requête ; Elle invoque la méthode service (HttpServletRequest

request,

HttpServletResponse response) en passant les deux objets en paramètres ;

Chapitre III : Introduction aux Servlets et pages JSP



Ladite méthode invoque la bonne méthode de traitement (doGet, doPost, doHead, doDelete, doPut,...) ; il y existe une méthode pour chaque type de requête HTTP, les plus utilisées sont o GET : méthode doGet() , c' est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet ; o POST : méthode doPost() , cette méthode doit être utilisée lorsqu'une requête modifie la ressource ;

Figure III-12 : Type de requête HTTP Le schéma ci-dessous explique la différence entre les requêtes de type Get et Post:  

Le traitement se fait ; La réponse est renvoyée au client.

Voici un schéma illustrant le cycle de vie d’une servlet (partant du principe que la servlet est initialisée)

Chapitre III : Introduction aux Servlets et pages JSP

Figure III-13 : cycle de vie détaillé d’une servlet A chaque fois que le conteneur reçoit une requête HTTP, il crée les objets requête et réponse puis, il crée un thread afin d'invoquer la méthode service (HttpServletRequest req, HttpServletREsponse rep)… Voici petit schéma résumant ce qu'il se passe lorsque deux personnes envoient une requête vers la même ressource sur le serveur :

Chapitre III : Introduction aux Servlets et pages JSP

Figure III-14 : traitement de deux requêtes par le serveur

1.3 Radiographie d’une première servlet Nous examinons l'exemple ci-dessus : La servlet Test.java import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class Test extends HttpServlet { public

void

doGet(HttpServletRequest

request,

response) throws IOException,ServletException{ response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println(" Hello World"); }

HttpServletResponse

Chapitre III : Introduction aux Servlets et pages JSP

} Le fichier web.xml est le suivant : Test firstServlet firstServlet /Serv1 /

La servlet : On notera les points suivants :  

la servlet HTTP hérite de la classe abstraite HttpServlet ; La méthode déclarée dans notre servlet contient le nom du type de



requête http envoyée : requête de type GET - méthode doGet. la méthode doGet de notre servlet prend deux objets en paramètres et ceux-ci ont des noms qui ressemblent beaucoup à requête HTTP et



réponse HTTP. Ensuite, le contenu de la servlet est très simple : o response.setContentType("text/html") : définit le type de réponse, ici, on retourne une page HTML ; o PrintWriter out = response.getWriter() : on récupère un objet permettant d'écrire dans la future page HTML ; o out.println("....") : écrit dans la page.

Chapitre III : Introduction aux Servlets et pages JSP

Le fichier descripteur web.xml Chaque application sur le serveur a une structure et cette structure est définie dans le fichier web.xml. Il existe Un seul fichier web.xml par application.Ce fichier est utilisé par le conteneur pour faire une relation entre une requête HTTP et une servlet (mapping des servlets). On dit aussi que le fichier sert à définir le contexte de l’ application. , ceci est tout simplement une sorte d'annuaire pour Tomcat : la définition des applications sur le serveur ainsi que la structure de celles-ci. On note les ponts suivants :  

Le contenu est englobé par une balise et La servlet est tout d'abord définie dans l'application via l'élément

. Deux éléments dans ce dernier : o : code réel de la servlet ; o : nom interne à l'application.  Ensuite, on trouve contenant les informations de paramétrage client : o : nom interne à l'application ; o : nom qui apparaît côté client. Voici un petit récapitulatif de ce qu'il se passe. 1/

Tomcat,

à

son

lancement,

prend

connaissance

des

données

mentionnées dans le fichier de configuration. 2/ Il reçoit une requête HTTP demandant "/", dans notre cas bien sûr. 3/ Il sait que ce nom est associé au nom de servlet "FirstServlet" qui, lui, correspond à la servlet com.servlet.test.DoIt. 4/ Celle-ci est instanciée et la méthode adéquate est invoquée. 5/ La réponse est récupérée par Tomcat qui renvoie cette dernière au client. Voici un petit schéma récapitulatif (les instanciations des objets requêtes et réponses sont tacites) :

Chapitre III : Introduction aux Servlets et pages JSP

Figure III-15 : recherche de la Ssevlet dans le fichier web.xml

2

Introduction aux JSP

2.1 Pourquoi une JSP? La technologie servlet est trop difficile d'accès et ne convient pas à la génération du code de présentation : écrire une page web en langage Java est horriblement pénible. Il est nécessaire de disposer d'une technologie qui joue le rôle de simplification de l'API servlet : les pages JSP sont en quelque sorte une abstraction "haut niveau" de la technologie servlet.

2.2 C’est quoi une JSP? Les pages JSP sont une des technologies de la plate-forme Java EE les plus puissantes, simples à utiliser et à mettre en place. Elles se présentent sous la forme d’une page HTML dans laquelle on peut ajouter du code Java (même principe qu„avec PHP). Pour que le serveur puisse différencier le code HTML du code JSP, il est nécessaire d’entourer les instructions JSP par des éléments de script spécifiques, appelés étiquettes ou encore balises JSP. Ecrire un script JSP demande donc d’acquérir une bonne connaissance du code HTML et d’apprendre à programmer en Java.

Chapitre III : Introduction aux Servlets et pages JSP

Exemple d’une portion de page JSP : Aujourd’hui, nous sommes le: IL existe deux syntaxes pour les Jsps : –Standard (JSP 1.2) –XML (JSP 2.0) On ne peut pas mixer les deux versions dans une même page. Il faut utiliser XML pou la page entière si on utilise la deuxième syntaxe.

2.3 Cycle de vie d'une JSP les

JSP

ont

un

cycle

de

vie

un

peu

plus

compliqué

que

les

servlets..Cependant, aussi complexe soit ce cycle de vie, toutes nos JSP sortiront de leurs chrysalides afin de se transformer en servlets et être utilisées par le conteneur.

Figure III-16 : CorrespondanceJSP/Servlet Exemple : CorrespondanceJSP/Servlet JSP d‟origine Time on server Servlet généré parTomcat

Chapitre III : Introduction aux Servlets et pages JSP

public final class XXX_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent{ public void _jspService(HttpServletRequest request, HttpServletResponse response) throws java.io.IOException, ServletException{ response.setContentType("text/html"); JspWriter out = response.getWriter(); out.write("Time on server\r\n"); out.write(""); out.print( new java.util.Date() ); out.write("\r\n"); baz(); } private int accessCount = 0 ; }

Le e cycle

de vie d’une jsp ressemble très fortement à celui de la vie

d'une servlet standard. Le schéma suivant représente le cycle de vie d'une JSP :

Chapitre III : Introduction aux Servlets et pages JSP

Figure III-17 : Cycle de vie d’une JSP Examinons un peu ce schéma : 1. Quelqu'un appelle une page JSP, via une URL ou en cliquant sur un lien. 2. La requête est dirigée vers le serveur de notre application. 3. Tomcat prend en charge la requête et s'aperçoit qu'une page JSP est demandée. 4. Il trouve ladite page et la convertit en fichier source java, en servlet pour être exact. 5. Ladite servlet est compilée et mise en mémoire, enfin prête à l'utilisation. 6. La méthode _jspInit() est invoquée. 7. Tomcat crée un nouveau thread pour traiter la demande et invoque dans ce thread la méthode _jspService(). 8. Le résultat, une page entièrement constituée de code HTML, est retournée par Tomcat au demandeur de départ, le client

2.4 Radiographie d’un Script JSP Considérons un exemple de code source d’un premier programme JSP qui affiche la liste suivante des réalisateurs et des films : L. Besson, le grand bleu; F. Truffaut, Jules et Jim; J.-J. Annaud, la guerre du feu; J,-J. Beinex, 37°2 le matin.

Chapitre III : Introduction aux Servlets et pages JSP

Cette liste doit s’afficher sous la forme d’un tableau à deux colonnes, la première pour les réalisateurs, la seconde pour les films réalisés par ces auteurs.



Un script JSP contient :  



Des balises HTML: , , , , , , , , etc; Des Balises JSP : o Les balises de commentaire ; o Les balises de déclaration ; o Les balises de scriptlet ; o Les balises d’expression ; o Les balises de directives. Des Variables Prédéfinis.

2.5 Les Balises JSP 2.5.1 Les balises de commentaire : Tout comme dans les langages Java et HTML, il est possible d'écrire des commentaires dans le code de vos pages JSP. Ils doivent être compris entre les balises . Ils sont uniquement destinés au(x) développeur(s), et ne sont donc pas visibles par l'utilisateur final dans la page HTML générée : Exemple :

Chapitre III : Introduction aux Servlets et pages JSP

2.5.2 Les balises de déclaration: Format : Syntaxe XML : Code Java Cette balise vous permet de déclarer une variable à l'intérieur d'une JSP. Cette déclaration se fait à l’aide des balises . Il est possible d'effectuer plusieurs déclarations au sein d'un même bloc. Exemple :

2.5.3 Les balises de scriptlets: Format Syntaxe XML : Code Java

Chapitre III : Introduction aux Servlets et pages JSP

Derrière ce mot étrange, un mélange atroce entre "script" et "servlet", se cache simplement du code Java. Elle sert en effet à inclure du code Java au sein des pages HTML Elle permet d’insérer à l’intérieur d’une page HTML toutes les instructions de type déclaration, test, boucle, et affichage décrites par le langage Java. Exemple :

2.5.4 Les balises d’expression Format Syntaxe XML : Java Expression La balise d'expression est en quelque sorte un raccourci de la scriptlet suivante : Elle retourne simplement le contenu d'une chaîne. NB : Une balise d’expression ne contient jamais de point-virgule.

Chapitre III : Introduction aux Servlets et pages JSP

Exemple : Dans l’exemple précédent la chaîne lAffiche contient les balises HTML ainsi que les noms des réalisateurs et des films. Cette liste de mots est stockées en mémoire mais n’est pas encore affichée par le navigateur. En insérant la chaîne lAffiche entre les balises , le contenu de la chaîne est envoyé au navigateur qui affiche un tableau.

2.5.5 Les balises de directive : Format : Les directives JSP permettent :   

d'importer un package ; d'inclure d'autres pages JSP ; d'inclure des bibliothèques de balises (nous y reviendrons dans un



prochain chapitre) ; de définir des propriétés et informations relatives à une page JSP.

Pour généraliser, elles contrôlent comment le conteneur de servlets va gérer votre JSP. Il en existe trois : taglib, page et include. Elles sont toujours comprises entre les balises , et hormis la directive d'inclusion de page qui peut être placée n'importe où, elles sont à placer en tête de page JSP.

Directive taglib Format : Le code inclut une bibliothèque personnalisée nommée maTagLib

Directive page Format

Chapitre III : Introduction aux Servlets et pages JSP

La directive page définit des informations relatives à la page JSP. Voici par exemple comment importer des classes Java : D'autres options sont utilisables via cette balise page, comme le contentType ou l'activation de la session.

Directive include Format En pratique, il est très courant de découper littéralement une page web en plusieurs fragments, qui sont ensuite rassemblés dans la page finale à destination de l'utilisateur. Cela permet notamment de pouvoir réutiliser certains blocs dans plusieurs vues différentes Pour permettre un tel découpage, la Directive include permet d’inclure le contenu d'un autre fichier dans le fichier courant. Exemple

2.6 Les variables prédéfinis : Quelques variables sont prédéfinies dans une page JSP, et peuvent donc être utilisées sans déclaration. 

request :

contient

une

référence

sur

l’objet

de

type HttpServletRequest qui contient la requête à cette page. Les en

têtes HTTP sont disponibles au travers de cet objet. response : référence sur le flux sortant de la servlet. Une JSP ne touche en général pas explicitement au flux sortant. Il est possible de

Chapitre III : Introduction aux Servlets et pages JSP

modifier l’en-tête HTTP via cet objet, y compris dans le corps de la  

page. out : Un Writer, utilisé pour envoyé des informations au client Session : variable de type Httpession. On peut donc lui attacher des objets, puisqu’une JSP est une servlet. Cette variable représente la



session dans laquelle se trouve la requête. application : variable de type ServletContext, à laquelle on peut aussi attacher des objets. Cette variable modélise l'application web dans laquelle on se trouve.

En résumé Dans ce chapitre nous avons réussi à faire un simple servlet et une simple jsp, et nous avons comprendre comment sont exécutés. Dans le chapitre suivant, nous allons voir que Les servlets ne servent pas à écrire du code Java dans des pages web, et démarrer avec des JSP pour des traitements complexes n’est pas pratique. En fait, la plateforme JEE implémente le pattern MVC.

CHAPITRE IV : IMPLEMENTATION DE MVC

Chapitre IV

Implémentation de MVC

OBJECTIFS L’objectif de ce chapitre est de :



1

Savoir faire la coopération entre servlet et jsp ;



Savoir envoyer et récupérer des données issues du client ;



Savoir envoyer et récupérer des données issues du serveur ;



Savoir utiliser les servlets et jsps pour implémenter le modèle MVC. MVC et Java EE

Avec la plate-forme JEE, nous allons devoir utiliser le pattern MVC. Nous avons vu que le pattern MVC est composé de trois entités (Modèle, Vue, Contrôleur) Si nous appliquons le pattern MVC à l'architecture JEE, ça nous donne : 

Dans le pattern MVC, il y a un objet qui a pour rôle de récupérer des demandes, de les traiter et de retourner ce qu'on lui a demandé : le contrôleur. En effet, nous avons fait en sorte que notre servlet écrive elle-même du code HTML, mais dans la plupart des cas, les servlets ont



pour

rôle

de

récupérer

les

requêtes

client

et

d'agir

en

conséquence Le modèle peut être divers et varié, comme tout modèle digne de ce nom :un objet Java basique ;un objet Java devant faire appel à une



base de données ; La vue, elle, reste une page web contenant du code HTML, à la différence près que celle-ci contiendra aussi du code Java : on appelle ces pages web des Java Server Pages, ou JSP

CHAPITRE IV : IMPLEMENTATION DE MVC

Figure IV-18 : MVC et Java EE Nous remarquerons que des flèches de dépendance ont disparu. En effet, nous allons voir que la vue est appelée par le contrôleur et reçoit les informations du modèle via ce dernier. 2

Collaboration entre JSP et servlets : l’interface requestdispatcher

Nous allons voir comment faire en sorte qu'une servlet puisse utiliser une JSP afin de la fournir au client.

Figure IV-19 : Collaboration entre JSP et servlets Pour

ce

faire,

nous

allons

appellerons InvokeJsp import java.io.*; import javax.servlet.*; import javax.servlet.http.*;

créer

une

nouvelle

servlet

que

nous

CHAPITRE IV : IMPLEMENTATION DE MVC

public class InvokeJsp extends HttpServlet { public

void

doGet(HttpServletRequest

request,

HttpServletResponse

response) throws IOException, ServletException{ RequestDispatcher dispatch =request.getRequestDispatcher("firstJsp.jsp"); dispatch.forward(request, response); } } Le fichier web.xml : InvokeJsp invoke invoke /invoke

Pour

accéder

à

cette

servlet,

il

suffit

d’aller

à

l'adresse

suivante : localhost:8080/Test/invoke nous aurons le contenu de notre JSP mais cette fois, celui-ci nous a été fourni par notre servlet InvokeJsp. Il est clair que ceci se faisait par le biais de ces deux lignes de code :

CHAPITRE IV : IMPLEMENTATION DE MVC

RequestDispatcher

dispatch

=

request.getRequestDispatcher("firstJsp.jsp"); dispatch.forward(request, response); //en contracté : request.getRequestDispatcher("firstJsp.jsp").forward(request,response); Un

objet

de

type RequestDispatcher est

obtenu

en

invoquant

la

méthode getRequestDispatcher(String) de la requête. Cet objet expose la méthodes : forward() qui redirige la requête vers la ressource désignée. Cette méthode prend en paramètre la requête et la réponse courantes. 3

Transmission de données: les paramètres et les attributs

3.1 Diférence entre paramètres et attributs Les paramètres de requête sont un concept appartenant au protocole HTTP. Ils sont envoyés par le client au serveur directement au sein de l'URL, et donc sous forme de chaînes de caractères. Ce concept n'étant absolument pas spécifique à la plate-forme Java EE mais commun à toutes les technologies web. Les paramètres sont donc des données issues du Client Les attributs de requête sont un concept appartenant au conteneur Java, et sont donc créés côté serveur : c'est au sein du code de l'application que l'on procède à leur initialisation. Contrairement aux paramètres, ils ne sont pas présents directement dans la requête HTTP mais uniquement dans l'objet Java qui l'enveloppe (l'objet HttpServletRequest), et peuvent contenir n'importe quel type de données. Ils sont utilisés pour permettre à une servlet de communiquer avec d'autres servlets ou pages JSP. Les attributs sont donc des données issues du Serveur

CHAPITRE IV : IMPLEMENTATION DE MVC

3.2 Transmission

des

attributs :

méthodes

setAttribute() et getAttribute() Pour transmettre des variables de la servlet à la jsp , le principe est très simple ; Il suffit d'appeler la méthode setAttribute() de l'objet requête pour créer un attribut dans une requête depuis une servlet, Cette méthode prend en paramètre le nom que l'on souhaite donner à l'attribut suivi de l'objet lui-même, et il suffit d'appeler la méthode getAttribute() pour en récupérer un depuis une JSP Exemple : Dans l’exemple suivant on récupère bien un objet nommé test. Public void doGet( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException{ String message = "Transmission de variables : OK !"; request.setAttribute( "testAttribut", message ); request.getRequestDispatcher(" test.jsp" ).forward( request, response ); } Code : test.jsp Ceci est une page générée depuis une JSP.

CHAPITRE IV : IMPLEMENTATION DE MVC



3.3 Transmission

des

paramètres :

méthode

getParameter() Un url peut prendre plusieurs formes :   

URL sans paramètres : /page.jsp URL avec un paramètre : /page.jsp?auteur=mohamed URL avec deux paramètres : /page.jsp?auteur=mohamed&livre=java

Pour récupérer un paramètre il suffit de faire appel à la méthode getParameter() de l'objet requête, en lui passant comme argument le nom du paramètre que l'on souhaite récupérer Exemple : Code : URL http://localhost:8080/test/toto?auteur=Coyote Code : Java - Servlet public

void

doGet(

HttpServletRequest

request,

HttpServletResponseresponse ) throws ServletException, IOException{ String paramAuteur = request.getParameter( "auteur" ); String message = "Transmission de variables : OK ! " + paramAuteur; request.setAttribute( "testAttribut", message ); this.getServletContext().getRequestDispatcher( »).forward( request, response ); } test.jsp

"test.jsp

CHAPITRE IV : IMPLEMENTATION DE MVC

Test Ceci est une page générée depuis une JSP. 4

Exemples d’applications du design pattern MVC :

Dans les exemples on utilisera les trois composantes de la plateforme JEE :    4.1

Modèle : objets Java ; Vue : pages JSP ; Contrôleur : servlet. Exemple1 :

L’objectif est d’afficher la liste des étudiants à partir d’une liste des promos .

CHAPITRE IV : IMPLEMENTATION DE MVC

Figure IV-20 : Liste des promos

Étape 1 : Le client récupère un formulaire (index.html) pour passer une requête avec paramètres (1, 2, puis 3)

Figure IV-21 : Étape 1 du modèle MVC

Formulaire : index.html

CHAPITRE IV : IMPLEMENTATION DE MVC

AREL V6.0 AREL: L'école virtuelle de l'EISTI Sélectionner la promo à afficher: ing1 ing2 Étape 2 : 1. Le client envoie son formulaire (GET/POST avec paramètres) 2. Le conteneur transmet au servlet correspondant (le controller)

CHAPITRE IV : IMPLEMENTATION DE MVC

Figure IV-22 : Étape 2 du modèle MVC

Controller : SelectPromo.java import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class SelectPromo extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet{ //... protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ String promoName = request.getParameter("promo"); //... } }

CHAPITRE IV : IMPLEMENTATION DE MVC

Configuration : web.xml MVC SelectPro SelectPromo SelectPro /SelectPromo Étape 3: 3. Le servlet controller interroge le model sur «ing2» 4. Le model retourne au controller le résultat correspondant

CHAPITRE IV : IMPLEMENTATION DE MVC

Figure IV-23 : Étape 3 du modèle MVC

Model : Promo.java import ...; public class Promo{ public List getPromo(String promo){ List promoList= new ArrayList(); if(promo.equals("ing1")){ promoList.add("Donald Duck"); promoList.add("Minnie Mouse"); promoList.add("Pluto"); //... } else if (promo.equals("ing2")){ promoList.add("Mickey Mouse"); promoList.add("Daisy Duck"); promoList.add("Goofy");//... } else{ return null;}

CHAPITRE IV : IMPLEMENTATION DE MVC

return promoList; } } Étape 4 : 5. Le controller utilise les données du model pour sa réponse 6. Le controller transmet sa réponse à la view (JSP)

Figure IV-24 : Étape 4 du modèle MVC Controller : SelectPromo.java import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class SelectPromo extends .HttpServlet implements javax.servlet.Servlet{ //... protected void doGet(HttpServletRequest request, HttpServletResponse response)

CHAPITRE IV : IMPLEMENTATION DE MVC

throws ServletException, IOException{ String promoName = request.getParameter("promo"); Promo promo = new Promo(); List result = promo.getPromo(promoName); request.setAttribute("promo", result); // // on ajoute l’attribut promo à la requête RequestDispatcher view = request.getRequestDispatcher("result.jsp"); view.forward(request, response); // On forward la requête à la JSP } } Étape 5 : 7. La JSP (view) traite la réponse transmise par le controller 8. La page HTML résultante est reçue par le client

Figure IV-25 : Étape 5 du modèle MVC View : result.jsp

CHAPITRE IV : IMPLEMENTATION DE MVC

Result Liste des promos :

CHAPITRE IV : IMPLEMENTATION DE MVC

Figure IV-26 : Liste des promos

4.2 Exemple 2 : Ici, nous avons un formulaire :   

qui s'appelle "formulaire" ; qui envoie les données des champs vers la page "/traitement" ; et qui envoie ces informations via une requête de type "post".

Figure IV-27 : Formulaire HTML En cliquant sur le bouton envoyer on obtient une page qui reçoit les informations et ressemble à ça :

CHAPITRE IV : IMPLEMENTATION DE MVC

Figure IV-28 : pages d'affichage des données de formulaire Les sources d’un formulaire On a

utilisé le couple servlet - JSP pour afficher le formulaire et pour

afficher les données de celui-ci. Voici les codes source de couple d'affichage de formulaires : Code: JSP-forms.jsp Formulaire HTML Nom : Prenom : Code : Java-Formulaire1.java import java.io.*; import javax.servlet.*; import javax.servlet.http.*;

CHAPITRE IV : IMPLEMENTATION DE MVC

public class Formulaire1 extends HttpServlet { public void doGet( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException{ request.getRequestDispatcher("forms.jsp").forward(request,response); } } Et le code source des pages d'affichage des données de formulaire : Code: JSP-formResult.jsp Vous avez saisi : Nom : Prénom : Pour retourner au formulaire, c'est par ici Code : Java-FormulaireAction .java

CHAPITRE IV : IMPLEMENTATION DE MVC

import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class FormulaireAction extends HttpServlet { public void doGet( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException{ request.getRequestDispatcher("formResult.jsp").forward(request, response); } public void doPost( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException{ doGet(request, response); } } Code : XML-web.xml com.servlet.test.Formulaire1 FirstForm

CHAPITRE IV : IMPLEMENTATION DE MVC

com.servlet.test.FormulaireAction FormAction FirstForm /form FormAction firstFormAction.do

En résumé Ce chapitre a décrit étape par étape l’implémentation de pattern MVC en imbriquant un servlet,une jsp et un simple objet java. Nous allons dans ce qui suit utiliser les javaBean dans cette architecture.

CHAPITRE V : JAVABEANS ET SCOPE

Chapitre V

JavaBeans et Scope

OBJECTIFS L’objectif de ce chapitre est de :

  

Savoir programmer des Javabeans ; Savoir utiliser les Javabeans ; Savoir implémenter le modèle MVC avec les Servlets, Jsps et les Javabeans.

1

JavaBeans

1.1 C’est quoi un Javabean Souvent raccourci en "bean", un JavaBean désigne tout simplement un composant réutilisable. Il est construit selon certains standards, définis dans les spécifications de la plate-forme et du langage Java eux-mêmes : un bean n'a donc rien de spécifique au Java EE. Autrement dit, aucun concept nouveau n'intervient dans la création d'un bean,. Son utilisation ne requiert aucune bibliothèque ; de même, il n’existe pas de superclasse définissant ce qu'est un bean, ni d'API. Ainsi, tout objet conforme à ces quelques règles peut être appelé un bean. Découvrons pour commencer quels sont les objectifs d'un bean, puis quels sont ces standards d'écriture dont je viens de vous parler. Enfin, découvrons comment l'utiliser dans un projet

1.2 Structure d’un Javabean Les

JavaBeans

sont

des

classes

Java(POJO)

qui

suivent

certaines

conventions: 

Doivent avoir un constructeur vide (zéro paramètre) : On peut satisfaire cette contrainte soit en définissant explicitement un tel constructeur, soit en ne spécifiant aucun constructeur ;

CHAPITRE V : JAVABEANS ET SCOPE



Ne



réutilisable par ailleurs ; La valeur des attributs doit être manipulée à travers des accesseurs



(getters et setters) ; Si une classe possède une méthode getTitle qui retourne un String, on

doivent

pas

avoir

d’attributs

publics,une

bonne

pratique

dit que le bean possède une propriété String nommée title . => Les propriétés Boolean utilisent isXXX à la place de getXXX

1.3 Comment utiliser des beans ? Une fois la classe créée, les beans sont des objets Java sur lesquels on peut faire ces actions :   

instanciation d'un nouveau bean récupération de la valeur d'une propriété du bean affectation/modification de la valeur d'une propriété du bean

Pour faire cela dans une Servlet, ça ne pose pas de problème particulier, le bean est traité comme un objet Java standard. Cependant, dans une JSP, l'utilisation des balises de scriptlets n'est pas très « propre », on utilisera plutôt l'une des manières suivantes : 

balises



utilisation des EL (JSP 2.0) (si le serveur le supporte) : ${...}

JSP

(JSP

1.2)

:

,

,

=> Dans ce cours nous verrons la deuxième approche, la première n'étant aujourd'hui utilisée que pour des raisons de compatibilités avec la version du serveur installé 2

Implémentation du MVC (avec les JavaBeans)

CHAPITRE V : JAVABEANS ET SCOPE

Figure V-29 : implémentation du MVC 1. Définir les beans pour représenter les données 2. Utiliser un servlet pour gérer les requêtes : Le servlet lit les paramètres de requêtes, vérifie les données manquantes ou malformées, appelle le code métier, etc. 3. Créer les beans : Le servlet invoque le code métier (spécifique à l’application) ou accède à une base de données pour obtenir les résultats. Les résultats sont dans les beans définis à l’étape 1 4. Placer le bean dans le bon scope (défini dans la suite du cours) : Le servlet appelle setAttribute sur la requête, la session, ou le servlet context pour garder une référence sur les beans qui représentent le résultat de la requête 5. Transmettre la requête à la JSP (forward) !) : Le servlet détermine quelle JSP est appropriée à la situation et utilise la méthode forward du RequestDispatcher pour transférer le contrôle à la JSP 6. Extraire les données des beans :

CHAPITRE V : JAVABEANS ET SCOPE



JSP 1.2: la JSP accède aux beans avec jsp:useBean et un scope correspondant



au

choix

de

l’étape

4.

La

JSP

utilise

ensuite

jsp:getProperty pour afficher les propriétés des beans JSP 2.0: la JSP utilise ${nameFromServlet.property} pour afficher les propriétés des beans

=> La JSP ne crée pas ou ne modifie pas les beans: c’est la vue du MVC. 24Exemple Modèle package model; public class PersonneBean { private String nom; private String prenom; public String getNom() { return nom; } public void setNom(String nom) { this.nom = nom; } public String getPrenom() { return prenom; } public void setPrenom(String prenom) { this.prenom = prenom; }

CHAPITRE V : JAVABEANS ET SCOPE

} Contrôleur import model.PersonneBean; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class MyServlet extends HttpServlet { protected void doGet(...) { String urlVue = "vue.jsp"; // URL de la vue à appeler String nom = request.getParameter("..."); // Récupération du champs nom //(par exemple via un formulaire) String prenom = request.getParameter("..."); // Récupération du champs prenom if(nom == null || nom.trim().equals("")) { // Erreur : nom non saisi } else if(prenom == null || prenom.trim().equals("")) { // Erreur : prenom non saisi } else // Cas sans erreur : on traite la requête, et crée les beans nécessaires { PersonneBean bean = new PersonneBean(); // Instanciation d'un bean

CHAPITRE V : JAVABEANS ET SCOPE

// de type PersonneBean bean.setNom(nom); // Affectation de la propriété nom bean.setPrenom(prenom); // Affectation de la propriété prenom request.setAttribute("myBean", bean); // Attacher ce bean au // scope de requête } // Forward à la vue: request.getRequestDispatcher(urlVue).forward(request, response); } } En MVC, les beans sont crées/modifiés par le contrôleur, en fonction de la requête du client et pas par la vue. Vue

  

”);

 

String nom=request.getParameter("nom");



String sexe=request.getParameter("sexe");



if (sexe!=null) {



out.println ("Le traitement:") ;



out.println ("Bonjour "+sexe,nom) ;



}



}

}

CORRECTION TDN° 2

 6. Écrire un formulaire «calculatrice» : 2 cases pour la saisie des opérandes, un groupe de 4 cases à cocher (ou une liste déroulante) pour le choix de l'opération, et affichage du résultat de l'opération 

public class exercice2 extends HttpServlet{



public void doGet(HttpServletRequest request, HttpServletResponse response)



throws ServletException, IOException {



response.setContentType("text/html");



PrintWriter out = response.getWriter();



out.println("Le formulaire:



















+



-



*



/





























CORRECTION TDN° 2







‘);



String aStr=request.getParameter("a");



String bStr=request.getParameter("b");



String par=request.getParameter("par");



if (par!=null) {



out.println("Le traitement") ;

 

int a=Integer.parseInt("0"+aStr);



int b=Integer.parseInt("0"+bStr);

 

out.println("Le résultat du calcul précédent est:



"+a,par,b+"=");



if (par.equals("+")) {



out.println(a+b);



} else if (par.equals("-")) {



out.println(a-b);



} else if (par.equals("*")) {



out.println(a*b);



} else if (b==0) {



out.println("Impossible..");



} else {



out.println(a/b);



}



out.println("") ;

CORRECTION TDN° 2



}

 

} }



 Exercice 4 

Tous ces exercices supposent l'existence du fichier «commun.jsp» suivant:           



1. Écrire un programme qui écrit 500 fois «Je dois faire des sauvegardes régulières de mes fichiers.». 

.













2. Écrire un programme qui calcule 20!

CORRECTION TDN° 2



.

























4. Écrire un formulaire qui demande le nom et l'âge de l'utilisateur. Le bouton submit de ce formulaire provoquera l'affichage d'une page qui saluera l'utilisateur avec cette phrase : «Bonjour machin, vous avez xx ans...» (avec les bonnes valeurs, bien entendu) 

.







Le formulaire :











Votre nom











Votre âge













 













Le traitement :

CORRECTION TDN° 2



Bonjour , vous avez ans.









5. Écrire un formulaire qui demande le nom et le sexe de l'utilisateur (M ou Mme). Ce formulaire appelle une page qui affichera «Bonjour monsieur Truc» ou «Bonjour madame Bidule» suivant le cas (avec le vrai nom de la personne, bien entendu!) 

.







Le formulaire :





 

Sexe



Monsieur 

Madame 





Nom













 













Le traitement :



Bonjour .









6. Écrire un formulaire «calculatrice» : 2 cases pour la saisie des opérandes, un groupe de 4 cases à cocher (ou une liste déroulante) pour le choix de l'opération, et affichage du résultat de l'opération 









Le formulaire :



Avec liste déroulante



















+



-



*



/

















CORRECTION TDN° 2

















   





























Le traitement 







Le résultat du calcul précédent est :



=











TDN° 3

TD N°3: Implémentation de MVC  Objectifs  

Se rappeler de l’architecture MVC ; Savoir créer une application selon le modèle



composants Jsps, Servlet et JavaBeans ; Savoir partager des données sur requête et sur session.

MVC avec les



 Exercice 1 

On considère l’application MVC que nous avons étudiée en cours. Cette

application

permet

à

l’utilisateur

de

sélectionner

une

promotion pour afficher la liste des étudiants correspondante. Voici les fichiers sources de cette application :  

index.html :











AREL V6.0











L'école virtuelle de l'EISTI



Sélectionner la promo à



afficher :



ing1



ing2















SelectPromotion.java :



import java…

TDN° 3



public class SelectPromotion extends HttpServlet



implements javax.servlet.Servlet {



protected void doGet(HttpServletRequest request,



HttpServletResponse response)



throws ServletException, IOException {



String promoName = request.getParameter("promo");



Promo promo = new Promo();



List result = promo.getPromo(promoName);



request.setAttribute("promo", result);



RequestDispatcher

view

request.getRequestDispatcher("result.jsp"); 

view.forward(request, response);



}



}

 

Promo.java : package arel;



import java.util.ArrayList;



import java.util.List;



public class Promo {



public List getPromo(String promo) {



List promoList = new ArrayList();



if (promo.equals("ing1")) {



promoList.add("Donald Duck");



promoList.add("Minnie Mouse");



promoList.add("Pluto");



//...



} else if (promo.equals("ing2")) {



promoList.add("Mickey Mouse");



promoList.add("Daisy Duck");



promoList.add("Goofy");

=

TDN° 3



//...



} else {



return null;



}



return promoList;



}



}



result.jsp :



























Result

















=

TDN° 3





 1. créez descripteur de déploiement

en fonction des liens et autres

nommages exprimés dans les fichiers sources donnés ci-dessus. 2. On désire modifier l’application pour afficher la liste résultat dans la même page que celle du formulaire initial. L’option choisie est de remplacer le formulaire HTML index.html par une JSP index.jsp servant à la fois de formulaire de départ et de vue dans l’application MVC pour afficher le résultat en dessous du formulaire.  

index.jsp :























AREL V6.0











L'école virtuelle de l'EISTI



Sélectionner la promo à



afficher :



ing1



ing2







Liste des étudiants :

TDN° 3









3. Lorsque l’on tente d’accéder à la JSP index.jsp, une erreur survient. Trouvez cette erreur et corrigez-la.

 Exercice 2 

Réalisez une application suivant l’architecture MVC permettant d’afficher un nombre aléatoire à l’utilisateur dans un intervalle donné en paramètre.



Note : Chaque requête doit fournir un nouveau nombre donc le partage sur requête est approprié.

 Exercice 3 

Réalisez une application suivant l’architecture MVC permettant d’afficher le nom et le prénom de l’utilisateur. Si l’utilisateur ne donne pas son nom, on affiche le nom qu’il a précédemment entré. S’il

n’y

a

pas

de

nom

antérieur,

on

affiche

un

message

d’avertissement. 

Note : Les données sont enregistrées pour chaque client, donc le partage sur session est approprié.



CORRECTION TDN° 3

Correction TDN°3 : Implémentation de MVC  Exercice 1 1. Créez descripteur de déploiement

en fonction des liens et autres

nommages exprimés dans les fichiers sources donnés ci-dessus.  

web.xml



MVC







X



arel.SelectPromo











X



/select-promo









 2. On désire modifier l’application pour afficher la liste résultat dans la même page que celle du formulaire initial. L’option choisie est de remplacer le formulaire HTML index.html par une JSP index.jsp servant à la fois de formulaire de départ et de vue dans l’application MVC pour afficher le résultat en dessous du formulaire. 

arel/SelectPromo.java



RequestDispatcher

view

=

request.getRequestDispatcher("index.jsp") ; 3. Lorsque l’on tente d’accéder à la JSP index.jsp, une erreur survient. Trouvez cette erreur et corrigez-la. 

Au premier lancement d’index.jsp, l’attribut promo n’existe pas dans le requestScope. Il faut donc tester s’il n’est pas null.



Ajouter un test de nullité :

CORRECTION TDN° 3







${requestScope["promo"]}

 Exercice 2 

Réalisez une application suivant l’architecture MVC permettant d’afficher un nombre aléatoire à l’utilisateur dans un intervalle donné en paramètre.



Note : Chaque requête doit fournir un nouveau nombre donc le partage sur requête est approprié.

 

Index.html











MVC Examples















Random Number

CORRECTION TDN° 3







Range:





















 

Le modèle package modele;

 

public class NumberBean // JavaBEAN car :



{



private double num; // Attributs privés

 

public NumberBean() // Constructeur sans paramètres



{



num = 0;



}

 

/**



* Getters et Setters



*/

 

public double getNumber()



{



return(num);



}

 

public void setNumber(double number)



{

CORRECTION TDN° 3



num = number;



}



}

 

Le contrôleur RandomNumberServlet



import …..



import modele.NumberBean;



public class RandomNumberServlet extends HttpServlet



{



private static final long serialVersionUID = 1L;

 

public

void

HttpServletResponse

doGet(HttpServletRequest response)

throws

request,

ServletException,

IOException 

{



NumberBean

bean

RanUtils.getRandomNum(request.getParameter("range"));

= //

Je

génère le bean par rapport au paramètre 

request.setAttribute("randomNum", bean); // Je l'ajoute dans le scope de requête



RequestDispatcher

dispatcher

request.getRequestDispatcher("vue.jsp"); // Je forward à ma vue 

dispatcher.forward(request, response);



}



}

 

import modele.NumberBean;

 

public class RanUtils

=

CORRECTION TDN° 3



{



public static NumberBean getRandomNum(String rangeString)



{



double range;



try



{



range = Double.parseDouble(rangeString);



}



catch(Exception e)



{



range = 10.0;



}



NumberBean n = new NumberBean();



n.setNumber(Math.random() * range);



return n;



}



}

 

Web.xml







index.html















NombreAleatoire



RandomNumber



RandomNumberServlet











RandomNumber

CORRECTION TDN° 3



/Rand









 

Vue.jsp















Random Number











Random Number:











 Exercice 3 

Réalisez une application suivant l’architecture MVC permettant d’afficher le nom et le prénom de l’utilisateur. Si l’utilisateur ne donne pas son nom, on affiche le nom qu’il a précédemment entré. S’il

n’y

a

pas

de

nom

antérieur,

on

affiche

un

message

d’avertissement. 

Note : Les données sont enregistrées pour chaque client, donc le partage sur session est approprié.

 

Index.html









CORRECTION TDN° 3



MVC Examples















Register







First Name:



Last Name:





















 

Le modèle package modele;



public class NameBean // JavaBEAN car :



{



private String firstName; // Attributs privés



private String lastName;

 

public NameBean() // Constructeur sans paramètre



{



firstName = "Missing first name";



lastName = "Missing last name";



}

 

/**



* Getters et Setters



*/



CORRECTION TDN° 3



public String getFirstName()



{



return(firstName);



}

 

public void setFirstName(String firstName)



{



if (!isMissing(firstName))



{



this.firstName = firstName;



}



}

 

public String getLastName()



{



return(lastName);



}

 

public void setLastName(String lastName)



{



if (!isMissing(lastName))



{



this.lastName = lastName;



}



}

 

private boolean isMissing(String value)



{



return((value == null) || (value.trim().equals("")));



}

CORRECTION TDN° 3



}

  

Le contrôleur Import…



import modele.NameBean;

 

public class RegistrationServlet extends HttpServlet



{



public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException



{



NameBean bean = (NameBean)request.getSession().getAttribute("nameBean"); // Je récupère le bean dans le scope de session



if (bean == null) bean = new NameBean(); // S'il n'existe pas encore je le crée



String firstName = request.getParameter("firstName"); // Je récupère le premier paramètre entré par l'utilisateur



String lastName = request.getParameter("lastName"); // Je récupère le deuxième paramètre entré par l'utilisateur



bean.setFirstName(firstName); // J'affecte le firstName au bean (si rien est entré le modèle ne le modifie pas)



bean.setLastName(lastName); // J'affecte le lastName au bean (si rien est entré le modèle ne le modifie pas)



request.getSession().setAttribute("nameBean", bean); // J'ajoute le bean dans le scope de session



RequestDispatcher dispatcher = request.getRequestDispatcher("vue.jsp"); // Je forward à ma vue



dispatcher.forward(request, response);



}

CORRECTION TDN° 3



}

 

Web.xml











index.html











RandomNumber



RegistrationServlet











RandomNumber



/Register









 

La vue