J2EE: Création des Applications Web d'Entreprise Basées Composants

J2EE: EXEMPLE DE SERVEUR

GlassFish

Ref http:// / ifsic-DIC2-ARC-LSI-Architecture JEE / p9 (eric hebert

25

Ref: www.oracle.com

26

LES COMPOSANTS D'UNE APPLICATION J2EE

Ref: http://www.cmg.org/measureit/issues/mit18/m_18_6.html

27

ARCHITECTURE D'UNE APPLICATION J2EE

Réf: http://www.cmg.org/measureit/issues/mit18/m_18_6.html

28

PROGRAMMATION CÔTÉ SERVEUR GÉNÉRATION DES PAGES HTML Servlet & JSP

29

OBJECTIF: PAGES HTML DYNAMIQUES

 Génération du code HTML à partir du serveur

 Parfois accompagné du style de la page;  Visant un client léger: Navigateur Web;  Envoi et récupération des données à partir du navigateur;

 Procédures:

 Exécuter un code différent sur une plateforme afin de

produire du code HTML;

 L'affichage obéira à plusieurs critères:

 Selon le type de données;  Selon le rôle de l'utilisateur;

30

GÉNÉRATION DES PAGES DYNAMIQUES: APPROCHES

 Exécution d'un programme:

 Un programme complet s'exécute et génère du contenu

HTML;

 La page est entièrement dynamique;

 Plus précisément : les partie statiques existent mais elles sont

intégrées dans le code, pas écrites directement en HTML standard;

 Le navigateur demande l'exécution d'un programme et

récupère le code HTML généré:  La demande d'exécution est transparente : utilise URL standard.

31

GÉNÉRATION DES PAGES: APPROCHES II

 Langages de scripts

 Double type de contenu dans une page HTML

 Partie statique : balises HTML standards avec contenu textuel;  Partie dynamique : du code écrit dans un langage de script:

 Ce code génère du code HTML standard.

 La page entremêle les parties statiques et dynamiques;  Quand un navigateur demande le contenu d'une page:

 La partie dynamique est exécutée et remplacée par le HTML

généré;

 Le navigateur du client reçoit donc uniquement du code HTML.

32

GÉNÉRATIONS DES PAGES: TECHNOLOGIES

 Langage de script:

 PHP;  Asp.net;  JSP.

 Exécution d'un programme

 CGI;  Servlet.

33

TECHNOLOGIES

 Protocole de communication:

 HTTP: le client invoque l'exécution des programmes dans

le serveur via ce protocole;  Serveur HTTP &/ou serveur d'application (conteneur)

 Serveur HTTP;

 Apache par exemple;

 Conteneur d'application (eventuels EJBs):

 GlassFish;  Tomcat &/ou Geronimo.

34

LES SERVLETS

 Servlet est un programme Java avec des caractéristiques

particulières:

 Accessible par une URL donnée:  Détecter et répondre à des requêtes de l'utilisateur;  Chercher et invoquer le traitement correspondant;  Générer une page Html et y mettre la réponse;

HTML

35

SERVLET II

 Applet: programme Java s'exécutant au niveau client;

 Servlet: Programme Java s'exécutant au niveau serveur;

 Classe Java avec ces méthodes et attributs;

 L'exécution et l'interactions différentes d'un objet Java

standard:

 Pas d'appel de constructeur, pas de main();  A la création de la servlet par le serveur d'exécution:

 Appel par le serveur d'exécution de la fonction init(ServletConfig);  On peut y faire les actions qu'on ferait dans un constructeur;

 Quand la servlet est détruite:

 Appel par le serveur d'exécution de destroy();  A redéfinir si on veut effectuer certaines actions à la suppression de

36

la servlet.

SERVLET: REQUÊTE-RÉPONSE

 Le client envoie les requêtes standards du HTTP:

 Post, Get, Put, Delete…

 Au niveau serveur chaque méthode reçue, son homologue

dans la Servlet est exécutée:

 Exemple: Requête Post trouve doPost() dans la Servlet;  Les méthodes doXXX héritent de la classe HttpServlet;  Les méthodes doXXX sont redéfinies pour y placer le

code à exécuter par la Servlet;

 En pratique, pas besoin de redéfinir toutes les méthodes

(GET et POST minimum).

37

SERVLET: EXEMPLE GET

doGet(HttpServletRequest request,

HttpServletResponse response)

throws ServletException, IOException

 request : contient la description de la requête du client;

 response : à utiliser pour envoyer la réponse au client;

 Toutes les méthodes doXXX(...) ont la même signature.

38

HTTPSERVLETREQUEST REQUEST

 Initialisé par l'appel du client (le navigateur);

 Données / informations sur la requête envoyée par le

client;

 On peut y récupérer notamment:

 Valeurs entrées pour un formulaire;  Une session pour gérer un état dédié à chaque client;  Cookies du client envoyés avec la requête;  Informations sur l'URL utilisée pour l'appel de la Servlet;  Login de l'utilisateur s'il s'est identifié.

39

HTTPSERVLETRESPONSE RESPONSE

 A initialiser et utiliser par la Servlet pour générer le

résultat à envoyer au navigateur client;

 Définir le type MIME des données envoyées

 Généralemet du code HTML

 response.setContentType("text/html;charset=UTF-8");  Récupérer le flux de sortie pour envoyer les données:

 PrintWriter getWriter()

 Flux texte, typiquement pour du HTML  ServletOutputStream getOutputStream  Flux binaire pour des images, vidéos ...  Ajouter/envoyer des données coté client

 Créer ou modifier un nouveau cookie;

40

SERVLET: CARACTÉRISTIQUES

 Unicité d'une Servlet:

 Une Servlet n'est créée qu'en une seule instance.

 Si plusieurs clients accèdent à l'URL d'une même Servlet:

 Appelle les méthodes sur cette instance unique.  Une Servlet possède des attributs donc un état:

 Cet état est permanent et conservé (tant que la Servlet

existe).

 Il est accédé / modifié par tous les clients : état global.

41

SERVLET: CARACTÉRISTIQUES II

 Pour chaque client accédant à la Servlet, le serveur lui

contribue un état (temporaire ou permanent):

 Temporaire:

 Pour chaque client, une session est créée;  On peut lui associer des données via des couples « clé (chaine) /

objet »;

 La session a une durée de vie configurable;  Exemple typique d'utilisation d'une session Panier d'un

utilisateur sur un site de vente en ligne : conserve les produits choisis par l'utilisateur pendant son parcours sur le site.

 Permanent:

 Création des cookies côté client.

42

SERVLET: STRUCTURE AVEC DOGET

import javax.servlet.*;

import javax.servlet.http.*;

public class SimpleServlet extends HttpServlet {

public void doGet(HttpServletRequest req,

HttpServletResponse res)

throws ServletException, IOException {

PrintWriter out = response.getWriter();

try { out.println("<html>");

out.println("<body>");

out.println(<h1> Coucou </h1>);

out.println("</body>"); out.println("</html>");

}}

public void destroy() {…}

43

SERVLETS: CRÉATION

 Une Servlet peut être chargée :

 automatiquement lors du démarrage du serveur Web;  lorsque le premier client demande les services de la

Servlet.

 Une fois chargées, les servlets restent actives dans

l'attente d'autres requêtes du client;

 La Servlet peut utiliser toutes les fonctions du langage

Java lors de la création de la réponse;

 Elle peut également communiquer avec des ressources

externes tels que des fichiers ou des bases de données, ou avec d'autres API (application ou composant Java).

44

 Exemple: d'autres Servlets.

SERVLET: OPPORTUNITÉS

 Les servlets exécutent un grand nombre de fonctions,

par exemple:

 Une Servlet peut créer et renvoyer une page Web HTML complète dont le contenu dynamique dépend de la nature de la requête du client;

 Une Servlet peut simplement créer une partie d'une page Web HTML qui est intégrée à une page HTML statique existante;

 Une Servlet peut traiter les connexions avec plusieurs clients en acceptant les données en entrée de plusieurs clients et en diffusant à ces derniers des résultats.

45

SERVLET: AVANTAGES

 Les servlets sont indépendantes des OS (Unix ou NT) et

des serveurs Web (Apache, IIS etc.) ;

 Peuvent produire de l'HTML côté client (notamment pour la consultation de la base), sur la base d'http;

 Peuvent dialoguer avec des applets Java côté client avec

un protocole à objets distribués de type RMI;

 S'appuient sur un langage vraiment standard : Java (et

non pas Java script ou Visual Basic);

 Par rapport aux applets, le client est « allégé » ;

 Par rapport aux CGI, les servlets prennent en charge les connexions des utilisateurs en multi-thread, qui n’est pas le cas des CGI.

46

SERVLET VS CGI

 La plus grande différence entre les CGI et les servlets

est la performance;

 Il n'y a qu'une seule machine virtuelle Java qui tourne

sur le serveur;

 La Servlet est placée en mémoire une fois qu'elle est

appelée. Elle n'est pas remise en mémoire jusqu'à ce que la Servlet change;

 Une Servlet dont le code a été modifié peut être réactivée

(c'est à dire replacée en mémoire) sans redémarrer le serveur ou l'application.

47

SERVLET VS CGI II

Req. CGI1

Req. CGI2

Req. CGI1

Processus Fils pour CGI1

Processus Principal

Processus Fils pour CGI2

CGI

Processus Fils pour CGI1

Req. servlet1

Req. servlet2

Req. servlet1

Processus Principal

Thread

Thread

servlet1

Les servlets

Thread

servlet2

48

SERVLET: PERFORMANCE

 Les servlets résident en mémoire, de ce fait leur

exécution est très rapide;

 L'information statique peut être partagée par plusieurs

invocations de la Servlet:

 Possibilité de partager cette information entre plusieurs

utilisateurs.

 Les servlets sont modulaires, chaque Servlet peut

accomplir une tache spécifique et ainsi vous pouvez les rendre communicantes.

 Moins il y a de calcul à faire côté client, plus l’approche

servlet est intéressante.

49

L'INTERFACE SERVLET

java.lang.Object

| +--javax.servlet.GenericServlet

| +--javax.servlet.http.HttpServlet

 Toutes les servlets implantent l'interface Servlet:

javax.servlet.Servlet

 soit directement ou bien via une classe qui implante cette interface,

comme:  javax.servlet.GenericServlet  (paquetage javax.servlet)  javax.servlet.http.HttpServlet  (paquetage javax.servlet.http)  particulièrement désignée pour des requêtes et réponses HTTP

50

L'INTERFACE SERVLET

 cette interface possède les méthodes pour :

 initialiser la servlet : init()  recevoir et répondre aux requêtes des clients : service()  détruire la servlet et ses ressources : destroy()

 la servlet est crée puis initialisée (init() )

 cette méthode n’est appelée par le serveur qu’une seule fois lors du

chargement en mémoire par le moteur de servlet.

 Le service du client est implémenté (service() )

 cette méthode est appelée automatiquement par le serveur à chaque

requête de client.

 la servlet est détruite (destroy() )

 cette méthode n’est appelée par le serveur qu’une seule fois à la fin  permet de libérer des ressources (allouées par init() ).

51

UNE SERVLET WEB : HTTPSERVLET

 Pour faciliter le traitement particulier des serveurs Web,

la classe Servlet est affinée en javax.servlet.http.HttpServlet

 2 méthodes remplacent service() de la classe mère :

 doGet() : pour les requêtes Http de type GET;  doPost() : pour les requêtes Http de type POST.

 la classe servlet doit obligatoirement contenir l’une ou l’autre de ces 2 méthodes redéfinies, choisies selon le mode d’envoi du formulaire HTML qui l'exécute;

 service() de HttpServlet appelle automatiquement la bonne

méthode en fonction du type de requêtes Http .

52

SERVLET: GESTION DES SESSIONS

 Service avec/sans état: Le serveur ne garde pas une

traçabilité sur la navigation du client:

 Parfois, dans quelques applications il est très utile de

reconnaitre l'utilisateur afin de poursuivre son activité sur le serveur.

 Deux techniques:

 Sessions;  Cookies.

53

SERVLET: GESTION DES SESSIONS II

 Champ caché: Les serveur peut inclure des informations

cachées dans un formulaire afin d'identifier la navigation du client:

<input type="hidden" name="sessionid" value="2013">  Le nom et la valeur de l'entrée sont automatiquement

inclus dans la méthode post ou get;

 A chaque fois le navigateur envoie une requête, le serveur

a la possibilité de suivre la navigation.

 Inconvénient: Le cas du href le serveur ne pourra pas

poursuivre la navigation.

54

SERVLET: GESTION DES SESSIONS III

 HttpSession: L'API Servlet fournit une interface

HttpSession qui permet de garder trace de l'utilisateur à travers plusieurs pages dans le même site.

 Il y a aussi la possibilité de stocker des informations à propos de l'utilisateur dans le site (meta-données).

 Le conteneur de Servlet utilise cette interface pour créer

une session entre un client et serveur http.

 La session persiste durant une période dans le temps (à définir par le développeur), à travers plusieurs pages et durant plusieurs connexions.

 Exemple:

HttpSession session = request.getSession();

55

SERVLET: GESTION DES SESSIONS IV

 Quelques méthodes utiles:

 Request.getSession(true) // pr la création de la session  getAttribute(String name)  Enumeration getAttributeNames()  long getCreationTime()  String getId()  long getLastAccessedTime()  boolean isNew()  setAttribute(String name, Object value)

56

SERVLET: GESTION DES SESSIONS V

 Exemple: doGest….. HttpSession session = request.getSession(true);

Date createTime = new Date(session.getCreationTime()); Date lastAccessTime = new Date(session.getLastAccessedTime()); Int visitCount =0; String visitCountKey = "visitCount"; String userIDKey = "userID"; String userID = "younes"; if (session.isNew()){

title = "Welcome to my website"; session.setAttribute(userIDKey, userID);

else {

}

visitCount = (Integer)session.getAttribute(visitCountKey); visitCount = visitCount + 1; userID = (String)session.getAttribute(userIDKey); } session.setAttribute(visitCountKey, visitCount); response.setContentType("text/html"); PrintWriter out = response.getWriter();

57

SERVLETS: GESTION DES COOKIES

 Un cookie: fichier texte stocké côté client enregistrant

toutes les interactions avec le serveur;

 Les informations d'un cookie aide le serveur à s'adapter à

un client particulier;

 C'est le serveur qui crée le cookie dans le client. Lors d'une

connexion le client envoie le cookie au serveur.

 Plusieurs caractéristiques:

 Les informations de navigation;  Les données saisies par le client dans un formulaires;  Durée de vie à définir par le serveur…

58

SERVLETS: GESTION DES COOKIES II

 Utiliser les fonctions de l ’API des servlets…

 créer un cookie : classe Cookie,  écrire/lire un cookie : addCookie(mycookie),

getCookies(),

 positionner des attributs d’un cookie : mycookie.setXxx(…)

 Exemple d'envoi d'un cookie :

... String nom = request.getParameter("nom"); Cookie myCookie = new Cookie("nom", "c le nom de

mon cookie");

...ici positionner des attributs si on le désire response.addCookie(myCookie); ...

59

SERVLETS: GESTION DES COOKIES III

 Quelques méthodes utiles:

 getValue/setValue;  getName/setName ;  getComment/setComment;  getMaxAge/setMaxAge :

 délai restant avant expiration du cookie (en seconde) par

défaut : pour la session courante.

 getPath/setPath :

 répertoire où s'applique le cookie dir. courant ou pages

spécifiques.

60

ANATOMIE D'UNE APPLICATION JAVA WEB

61

DESCRIPTEUR DE DÉPLOIEMENT: WEB.XML

 Il s'agit d'un fichier situé dans le répertoire WEB-INF du

répertoire racine de l'application web.

 Il contient les caractéristiques et les paramètres de

l'application.

 la description des servlets utilisées;  les différents paramètres d'initialisation.

 Il représente un schéma pour le serveur afin de relier les

Servlets avec leurs compilations et leurs paramètres dans le serveur.

62

SQUELETTE DE BASE DU WEB.XML

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> ... </web-app>

 Toutes les descriptions de l'application sont insérées

dans la balise <web-app>;

 C'est au niveau de cette balise le serveur cherche les

Servlets et leurs paramètres.

63

WEB.XML: <WEB-APP>

 On y trouve deux balises pour la description de

l'application (pas d'influence technique):

 display-name permet de donner un nom à l'application. Il s'agit

de description, pour s'y retrouver dans les fichiers;

 La balise description permet de fournir une description plus

détaillée. elle est inopérante techniquement parlant.

<web-app> ... <display-name>Application pr mon stage</display-name> <description>Cette première application web est un exemple permettant de présenter le déploiement d'une webapp. </description> ... </web-app>

64

WEB.XML ET LES SERVLETS:

 Une Servlet est toujours déclarée entre <servlet> et

</servlet>

 On doit affecter un nom à chaque Servlet déclarée, dans

une balise servlet-name.

 Ce nom n'est pas nécessairement le nom de la classe de la

servlet.

 la balise description permet de fournir une information

sur la Servlet;

 la balise servlet-class permet de définir la classe de la Servlet. La classe doit se trouver dans le répertoire WEB-INF/classes de l'application, en respectant les packages.

65

WEB.XML ET LES SERVLETS II

 La balises init-param permet de spécifier des paramètres

d'initialisation pour une servlet.

 Des paramètres chargés en même temps que la servlet, et

qu'elle peut récupérer.

 La balise param-name permet de définir le nom du paramètre,

et param-value pour spécifier la valeur.

 L'application peut récupérer un tel paramètre grâce à la

méthode getServletConfig().getInitParameter("random")  La balise load-on-startup demande que la servlet soit chargée

dès le démarrage du serveur (et non lors de sa première sollicitation). Le nombre entier situé à l'intérieur de ces balises représente l'ordre de chargement.

66

WEB.XML: MAPPING DES SERVLETS

 Le mapping d'une Servlet sert à indiquer au serveur

quelle Servlet charger pour tel requête du client (telle URL demandée). Rappelons que les URL des servlets sont relatives à l'URL du context (la webapp) auquel elles appartiennent.

<web-app> ... <servlet-mapping> <servlet-name>maservlet</servlet-name> <url-pattern>/uneservlet</url-pattern> </servlet-mapping> ... </web-app>

67

WEB.XML ET LES SERVLETS:

<web-app> ... <servlet> <servlet-name>maservlet</servlet-name> <servlet-class>org.test.servlet.PremiereServlet</servlet-class> <description>des servlets pr le test</description> <init-param> <param-name>random</param-name> <param-value>org.test.randomizer</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> ... </web-app>

68

SERVLET: LIMITATION

 Par rapport aux applets, interface graphique utilisateur

limitée à HTML;

 Solution d'autre framework de présentation (JSF par

exemple);

69

JSP: JAVA SERVER PAGE

70

VUE D'ENSEMBLE

 La spécification J2EE permet aux utilisateurs de

développer des pages statiques et dynamiques:

 La partie statique: pure Html;

 La partie dynamique: langage Java.

 Deux possibilités:

 API Servlet: du code Java dans lequel on insère du Html;

 API JSP: une page Html dans laquelle on insère du Java.

71

Y. EL BOUZEKRI EL IDRISSI

COMMENT ÇA MARCHE?

 Le développeur a la possibilité d'insérer du code java dans le fichier Html à l'aide des balises prédéfinies;

 Le moteur des JSP (Serveur d'app) reconnait ces balises, puis procède à leur compilation et leur exécution;

 Le serveur traite les balises html et java

différemment afin de créer une Servlet équivalente à la JSP, l'exécution de cette dernière génère le code Html équivalent au résultat.

 NB: possibilité aussi de générer du code Xml.

72

Y. EL BOUZEKRI EL IDRISSI

CYCLE DE VIE D'UNE JSP

Moteur JSP

Compilation de laJSP

Servlet équivalente

Serveur Web

Client

73

Y. EL BOUZEKRI EL IDRISSI

EXEMPLE SIMPLE: DATE()

 Datecourante.jsp

<html> <title> Ma JSP</title> <body> La date retournée par la JSP <% = new Java.util.Date() %> </body> </html>

74

Y. EL BOUZEKRI EL IDRISSI

LES BALISES JSP

 Toutes les balises JSP doivent être entre <% %>;

 Elles représentent les éléments de base pour construire la

Servlet (lors de l'instanciation);

 On peut introduire plusieurs instructions Java dans une

balise, comme on peut créer plusieurs balises Java indépendantes;

 L'emplacement des balises dans le serveur est le dossier Web,

tandis que, dans une application J2EE est le WebContent

75

Y. EL BOUZEKRI EL IDRISSI

LA SYNTAXE DES BALISES

 On distingue cinq types de balise JSP:

 Les commentaires:

 < -- hello -- >

 Scriplets: insertion du code Java:

 <% System.out.println("hello"); %>

 L'affichage des valeurs:

 <%= "hello" > équvalent à <% System.out.println("hello"); %>

 Balise de déclaration globale:

 <%! Int compteur; %>

 Directives et paramètres à appliquer sur la JSP:

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

76

Y. EL BOUZEKRI EL IDRISSI

<%! BALISE %>

 L'objectif de cette balise est de déclarer des membres

globaux de la Servlets:

 Méthodes;

 Variables;

 Exemples:

 <%! Int compteur = 0; %>

 <%! Int somme (int a, int b) {

return a+b; ] %>

77

Y. EL BOUZEKRI EL IDRISSI

SCRIPLET <% %>

 L'objectif est d'insérer plusieurs instructions Java

dans la même balise;

 A remarquer que les variables déclarées dans la

Scriplet, leur porté ne dépasse pas la fermeture de la

balise;

 Exemple:

<% int x = "chaine"; for (int i=0; i<10; i++) out.println(x); %>

78

Y. EL BOUZEKRI EL IDRISSI

<%@ BALISE DES DIRECTIVES %>

 L'objectif est le paramétrage de la page pour la

compilation;

 Les directives en jeu:

 Page:

 Include:

 Taglibs

 Syntaxe:

<%@directive param=valeur [param=valeur...] %>

79

Y. EL BOUZEKRI EL IDRISSI

DIRECTIVE: INCLUDE

 Permet d'insérer un fichier texte brut ou une autre

ressource textuelle;

 Lors de la compilation, exactement à la conversion

vers une Servlet, le moteur JSP inclut le texte

externe;

 Il s'agit d'une forme d'entité externe à insérer,

comme si elle faisait partie du fichier:

 Exemple:

<%@Include file="c:\partie.txt"] %>

80

Y. EL BOUZEKRI EL IDRISSI

DIRECTIVE PAGE

 Contrôle des attributs de la page et du Servlet:

 Paramètres :

 contentType – type de contenu (text/html);

 <%@page contentType="(text/pl ain)"%>

 import – Classes Java è utiliser;

 <%@page import="java.util.*"%

 errorPage – Page à afficher en cas d’erreur;

 <%@page errorPage="/erreur.jsp"%>

 isErrorPage – Si la page est une page d’erreur;

81

 session – Si la page fait partie d’une session;

Y. EL BOUZEKRI EL IDRISSI

DIRECTIVE PAGE: ISERRORPAGE

Mapage.jsp

<%@page language="Java" contentType="Text/html"%> <%@page errorPage="/casderreur.jsp"%> <html>……..</html>

Errorpage.jsp

<%@page language="Java" contentType="Text/html"%> <%@page isErrorPage="true"%> <html>…. <%=exception.getClass().getName()%>< /html>

82

Y. EL BOUZEKRI EL IDRISSI

DIRECTIVE: TAGLIBS

 L'API JSP permet à l'utilisateur de définir des

balises personnalisées (ou une bibliothèque de tag)

de la page JSP;

 Il s'agit de définir un comportement personnalisé de

la page JSP;

 La déclaration de la directive Taglib vous permet

l'utilisation de tag personnalisée et un moyen de les

appeler:

 URI

 Préfix

83

Y. EL BOUZEKRI EL IDRISSI

DIRECTIVE: TAGLIBS

<%@ taglib uri="uri" prefix="prefixOfTag" >

 Exemple; La librairie custlib et le préfixe mytag

<%@ taglib uri="http://www.example.com/custlib"

prefix="mytag" %>

<html>

<body>

<mytag:hello/>

</body>

</html>

84

Y. EL BOUZEKRI EL IDRISSI

TAGLIB : TUTO

 Pour y faire il faut deux étapes:

 Déclaration d'une classe:

 Déclaration de la tag dans fichier tld

mmmmm.tld

<taglib>

<tlib-version>1.0</tlib-version> <jsp-version>2.0</jsp-version> <short-name>Example TLD</short-name> <tag>

<name>Hello</name> <tag-class>com.tutorial.HelloTag</tag-class> <body-content>empty</body-content>

</tag> </taglib>

import javax.servlet.jsp.tagext.*; import javax.servlet.jsp.*; import java.io.*;

public class HelloTag extends SimpleTagSupport {

public void doTag() throws JspException,

IOException {

JspWriter out = getJspContext().getOut(); out.println("Hello Custom Tag!");

}

}

85

Y. EL BOUZEKRI EL IDRISSI

DESIGN PATTERN MVC

86

Struts dans votre web application

LE DESIGN PATTERN MVC

 Design pattern (modèle patron): Une démarche qui est

proposée, puis utilisée et finalement fait preuve de son

performance:

 Son utilisation est très recommandée.

 MVC: une démarche pour la création des applications,

particulièrement Web dont le contenu est décomposé selon sa nature:

 Données, leurs présentations et la gestion des événements

envoyés par un utilisateur.

87

Y. EL BOUZEKRI EL IDRISSI

MVC: MODEL-VIEW-CONTROLLER

 L'objectif d'une architecture Model-View-Controller

est l’organisation d'une application par la séparation

 les données et leurs traitements;

 la représentation des données;

 le comportement de l ’application.

 Avantages:

• Réutiliser le code;

• Réduire les temps de développement;

• Simplifier la maintenance.

88

Y. EL BOUZEKRI EL IDRISSI

MVC: COMPOSANTS

 Le modèle: définit la structure des données et les

opérations à appliquer sur elles.

 Une Vue: définit la partie IHM, et les règles

d'affichage des données afin de les adapter sous un

contexte particulier;

 Un Controller: définit les écouteurs des actions

émises par l'utilisateur sur le modèle et génère la

vue appropriée.

89

Y. EL BOUZEKRI EL IDRISSI

MODÈLE

 Encapsuler les propriétés des données:

 Être indépendant des vues et contrôleurs.

 Définir les accesseurs aux propriétés de ces données;

 Maintenir une liste d'écouteurs (vues et contrôleurs);

 Prévenir les écouteurs lorsque la donnée est modifiée;

 les résultats renvoyés par le modèle sont indépendants de

toute présentation.

 Contenir toute la logique métier de l'application.

90

Y. EL BOUZEKRI EL IDRISSI

LA VUE

 Se charge de la logique d'affichage des données

(éventuellement des résultats), elle n'effectue aucun traitement;

 L'interface qui permet à l'utilisateur d'interagir avec

l'application:

 recevoir toutes les actions de l'utilisateur (clic,

sélection…);

 événements envoyés au contrôleur;

91

Y. EL BOUZEKRI EL IDRISSI

CONTRÔLE

 Traduit les interactions de l'utilisateur à partir d'une

requête HTTP;

 Gère les événements entre le modèle et la vue par

des appels de méthodes sur le modèle et sélectionne

la vue appropriée:

 Il appelle les méthodes du modèle afin d'appliquer des

modifications sur les données;

 Pas d'accès directe tout se passe par la couche métier du modèle;

 Synchronisation.

92

Y. EL BOUZEKRI EL IDRISSI

SCÉNARIO

Modele

1

Controller

Client

5

2

3

4

view

93

Y. EL BOUZEKRI EL IDRISSI

SCÉNARIO DÉTAILLÉ

Client

Controller 2

Controller 1

View 1

View 2

Métier

DAO

Modele

DB

94

Y. EL BOUZEKRI EL IDRISSI

MVC2

 L'objectif est de simplifier encore plus le

développement par la limitation des interactions

entre les vues et les contrôleurs;

 La démarche c'est d'introduire un seul contrôleur

(principal) vis-à-vis des vues, ce dernier se chargera

de trouver le contrôleur spécialisé adéquat;

95

Y. EL BOUZEKRI EL IDRISSI

MVC2 DÉMARCHE

 L'interaction d'un utilisateur est interceptée par le

contrôleur principal;

 Le contrôleur spécialisé adéquat est appelé avec la requête en paramètre par le contrôleur principal;

 Le contrôleur spécialisé demande au modèle

approprié d'effectuer les traitements;

 le contrôleur spécialisé sélectionne la vue adaptée