Université Ibn Zohr

Faculté des Sciences d’agadir

Centre d’excellence IT

Plateforme Java EE
Développement d’application d'Enterprise

Technologie JSP

Pr. N. RIDA
Modèle MVC : vue [JSP]
Pages (JSP): Des Servlets avec vue

Couche Web en MVC

Nature WEB
d’une page
JSP
Request

Controller
Quoi ?
Servlet
Les pages JSP sont une des technologies de la plate-forme Java-EE les
Response
plus puissantes, simples à utiliser et à mettre en place.
Elles se présentent sous la forme d'un simple fichier au format texte,
contenant des balises respectant une syntaxe à part entière.
Vue Model
Le langage JSP combine à la fois les technologies HTML, XML, servlet et JSP
JavaBeans en une seule solution permettant aux développeurs de créer
des vues dynamiques.
Modèle MVC : Contrôleur [SERVLET] et vue [JSP]
SERVLET VS JSP
• Une servlet est une classe java dans laquelle on peut générer du code HTML
• Une JSP est une sorte de page HTML à l’intérieur de laquelle, o peut écrire du code Java.

• Les pages JSP sont très pratique quand on veut afficher les vues de l’applications
• Les servlets sont pratique pour effectuer les traitements nécessaires au fonctionnement d’une application.

• Une servlet nécessite d’être déployée (web.xml),

• Alors qu’une JSP est déployée automatiquement par Tomcat.

• Pendant le premier appel d’une JSP, Tomcat convertit la JSP en servlet et la déploie automatiquement.
• Quand un client HTTP demande une page JSP, c’est la servlet correspondante à cette JSP, qui est générée par Tomcat
qui est exécutée.

• Tout ce qu’on peut faire avec une servlet, peut être fait par une JSP (Une JSP est une servlet)
• La technologie de base des applications web JEE c’est les servlets.

• Une JSP est intimement liée à une servlet. En fait, une fois la compilation effectuée, la JSP devient une servlet.
Donc les objets request, session, out, …etc. reste accessibles dans une page JSP.

• Dans une application web JEE qui respecte le pattern MVC :

 Les servlets sont utilisées pour jouer le rôle du contrôleur
 Les JSP sont utilisées pour jouer le rôle des vues
Modèle MVC : vue [JSP]
Pages (JSP): Des Servlets avec vue

Couche Web en MVC

À quoi ressemble une page JSP ?
WEB

C’est une document qui ressemble beaucoup à une page HTML, Request
mais qui en réalité en diffère par plusieurs aspects :
Controller
✔ l'extension d'une telle page devient .jsp et non plus .html
Servlet
✔ une telle page peut contenir des balises HTML, mais
également des balises JSP qui appellent de manière Response
transparente du code Java <% JAVA
</ HTML
✔ contrairement à une page HTML statique directement
renvoyée au client, une page JSP est exécutée côté serveur, et Vue Model
génère alors une page renvoyée au client.
JSP
Modèle MVC : vue [JSP]
Pages (JSP): Des Servlets avec vue

Couche Web en MVC

Nature
d’une page WEB
JSP
Vue Controller
JSP Servlet
Pourquoi ?
Model
les raisons de l'existence de cette technologie

• La technologie servlet est trop difficile d'accès et ne convient pas à la génération du code de présentation
o Écrire une page web en langage Java est horriblement pénible.
o les pages JSP sont en quelque sorte une abstraction "haut niveau" de la technologie servlet. (JSP : simplification de l'API servlet )
• Le modèle MVC recommande une séparation nette entre le code de contrôle et la présentation.
o Il est théoriquement envisageable d'utiliser certaines servlets pour le contrôle, et d'autres pour effectuer l'affichage, mais la
servlet n'est pas adaptée à la prise en charge de l'affichage…
• Le modèle MVC recommande aussi une séparation nette entre le code métier et la présentation
Modèle MVC : vue [JSP]
Pages (JSP): Cycle de vie
Conteneur de Servlets

Requête HTTP JSP Oui

a-t-elle Page JSP
Changé ?
.JSP
Le processus de vérification/traduction/compilation n'est
pas effectué à chaque appel ! Traduction de la JSP en Servlet
La servlet générée et compilée étant sauvegardée, les
appels suivants à la JSP sont beaucoup plus rapides : le Non Servlet
conteneur se contente d'exécuter directement l'instance de .java
la servlet stockée en mémoire.
Compilation de la Servlet

Réponse HTTP
Instance de Servlet
Servlet Servlet chargée .class
Modèle MVC : vue [JSP]
Pages (JSP): Mise en place

Une page JSP par défaut est alors générée par Eclipse
Création
d’une page
JSP
Modèle MVC : vue [JSP]
Pages (JSP): Mise en place

Création
d’une page
JSP
 LoginJSP.java
Login.jsp
Modèle MVC : vue [JSP]
Pages (JSP): Mise en relation avec notre servlet

Le modèle de conception MVC nous recommande en effet la mise en place d'un contrôleur, dont nous
MVC
allons donc tâcher de toujours associer à une vue.

Mais on viens de montrer qu'une JSP était de toute façon traduite en servlet…
Quel est l'intérêt de mettre en place une autre servlet ?

les servlets résultant de la traduction des JSP dans une application n'ont pour rôle que de permettre la
manipulation des requêtes et réponses HTTP.
En aucun cas elles n'interviennent dans la couche de contrôle, elles agissent de manière transparente et
font bien partie de la vue : ce sont simplement des traductions en un langage que comprend le serveur (le
Java !) des vues présentes dans votre application (de simples fichiers textes contenant de la syntaxe JSP).

Systématiquement on va créer une servlet lorsque nous créerons une page JSP.
C’est une bonne pratique à prendre pour gardez le contrôle, en s’assurant qu'une vue ne sera jamais appelée par le client sans être
passée à travers une servlet.
La servlet est le point d'entrée de notre application
Pour cela on va déplacer nos pages JSP dans le répertoire /WEB-INF.
Modèle MVC : vue [JSP]
Pages (JSP): Mise en relation avec notre servlet Client HTTP Serveur
Cette opération est réalisée depuis la servlet, ce qui est WEB
logique puisque c'est elle qui décide d'appeler la vue

Request

Controller
Requête
HTTP
Servlet
Response
Réponse
Depuis la servlet (this), nous appelons la méthode getServletContext().
HTTP forward
Celle-ci nous retourne alors un objet ServletContext, qui fait référence au
contexte commun à toute l'application : qui offre un ensemble de méthodes
permettant à une servlet de communiquer avec le conteneur de servlet ; Vue JSP
getRequestDispatcher(), retourne un objet RequestDispatcher, qui agit ici
comme une enveloppe autour de notre page JSP.
Utilisé pour que la servlet soit capable de faire suivre nos objets requête et
réponse à une vue.
Il est impératif d'y préciser le chemin complet vers la JSP, en commençant
l'objet HttpServletRequest, contient lui aussi une méthode
obligatoirement par un /
getRequestDispatcher() qui peut prendre en argument un
nous utilisons enfin ce dispatcher pour réexpédier la paire requête/réponse chemin relatif, alors que sa grande sœur n'accepte qu'un
HTTP vers notre page JSP via sa méthode forward(). chemin complet.
Modèle MVC : vue [JSP]
JSP Servlet: Transmission de données
Client HTTP Serveur
Notre contenu est présent dans une page JSP à laquelle nous
WEB
avons associé une servlet.
Pour ajouter du dynamisme à notre projet. Il est temps
d'apprendre à faire communiquer entre nos composants web Request
les différents données constituant notre application.
Controller
Requête
Il y a deux types de données à transmettre entre nos HTTP
Servlet
composants WEB :
Response
Réponse
• Données issues du serveur : les attributs HTTP
• Données issues du client : les paramètres
Att Données Params

Vue JSP
Modèle MVC : vue [JSP]
JSP < Servlet: Données issues du Serveur : les attributs
Transmettre des variables de la servlet à la JSP : Client HTTP Serveur

Jusqu'à présent nous n'avons pas fait grand-chose avec notre requête WEB
HTTP, (l’objet HttpServletRequest ) nous nous sommes contentés de le
transmettre à la JSP.
Puisque notre requête HTTP passe maintenant au travers de la servlet Request
avant d'être transmise à la vue, profitons-en pour y apporter quelques
modifications ! Controller
Utilisons donc notre servlet pour mettre en place un semblant de
Requête
dynamisme dans notre application : Servlet
HTTP

Response
Réponse

HTTP

Att Données

Vue JSP
Mon objet se nomme message mais j'ai nommé par la suite MSG l'attribut qui contient cet objet dans la requête.
Côté vue, c'est par ce nom d'attribut que vous pourrez accéder à votre objet !
Modèle MVC : vue [JSP]
JSP < Servlet: Données issues du Serveur : les attributs
Côté page JSP : Client HTTP Serveur
la technologie JSP. permet d'inclure du code Java dans notre code html
en entourant ce code des balises <% et %> . Ce sont des marqueurs qui WEB
délimitent les portions contenant du code Java du reste de la page.
Request
La seule différence réside dans le fait que depuis une JSP, il n'est plus
nécessaire de récupérer l'objet PrintWriter, comme nous l'avions fait
depuis notre servlet. Ceci est rendu possible grâce à l'existence d'objets Controller
implicites, sur lesquels nous allons revenir très bientôt ! Requête

HTTP
Servlet
Pour récupération de l'attribut depuis la requête, par analogie avec la
création de l’attribut, il suffit d'appeler la méthode getAttribute() pour Response
le récupérer un depuis une JSP ! Réponse

HTTP

Att Données

Vue JSP
Modèle MVC : vue [JSP]
JSP < Servlet: Données issues du Serveur : les attributs
Client HTTP Serveur

WEB

Request

Controller
??? Requête
Écrire du Java dans une JSP n'a aucun sens : l'intérêt même de ces pages HTTP
Servlet
est de s'affranchir du langage Java
Response
Mais cela confirme qu’en Java EE, rien n'impose au développeur de bien Réponse
travailler comme il veut, il est possible de coder n'importe comment sans HTTP
que cela n'impacte le fonctionnement de l'application.
Att Données

On a utiliser du code Java ici, parce que nous n'avons pas encore découvert
le langage JSP. D'ailleurs, à partir du chapitre suivant, nous allons tout
mettre en œuvre pour ne plus jamais écrire de Java directement dans une
JSP ! Vue JSP
Modèle MVC : vue [JSP]
JSP > Servlet: Données issues du Client : les paramètres
Paramètre de requête : Client HTTP Serveur

la méthode GET du protocole HTTP permet au client de transmettre des WEB

données au serveur en les incluant directement dans l'URL, dans ce qui
s'appelle les paramètres ou query strings en anglais.
Request
<!-- URL sans paramètres -->
/page.jsp
Controller
<!-- URL avec un paramètre nommé 'lg' et ayant pour valeur 'java’ -->
Requête
/page.jsp?lg=java
HTTP
Servlet
<!-- URL avec deux paramètres nommés 'lang' et 'admin', et ayant pour valeur
respectivement 'fr' et 'true'--> Response
/page.jsp?lang=fr&admin=true Réponse

HTTP

la taille d'une URL étant limitée, la taille des données qu'il est ainsi Données params
possible d'envoyer est limitée également !
Autrement dit si votre URL est si longue qu'elle contient plus de 2 000
caractères par exemple, ce navigateur ne saura pas gérer cette URL !
Préférez dans ce cas la méthode POST
Vue JSP
Si vous envoyez des données ayant un impact sur la ressource demandée, il est, là
encore, préférable de passer par la méthode POST du protocole, plutôt que par la
méthode GET.
Modèle MVC : vue [JSP]
JSP > Servlet: Données issues du Client : les paramètres
Avoir un impact sur la ressource : Client HTTP Serveur

Cela veut dire "entraîner une modification sur la ressource", mais en fin de compte tout WEB
dépend de ce que vous faites de ces données dans votre code.

Request
Exemple :
Controller
Imaginons une application proposant une page compte.jsp qui autoriserait
Requête
des actions diverses sur le compte en banque de l'utilisateur.
HTTP
Servlet
L’envoi d’un paramètre mois pour afficher la liste des E/S d'argent du compte, i.e.
compte.jsp?mois=avril, n'aura pas d'impact sur la ressource. Même si on renvoit 10 fois la Response
Réponse
requête au serveur, notre code ne fera que réafficher les mêmes données sans les
modifier. HTTP

Par contre l’envoi de paramètres précisant des informations nécessaires pour faire un Données params
transfert d'argent, i.e. compte.jsp?montant=100&destinataire=01K87B612, aura
clairement un impact sur la ressource : en effet, si nous renvoyons 10 fois une telle
requête, notre code va effectuer 10 fois le transfert !

nous pouvons utiliser une requête GET pour le premier cas, et devons utiliser Vue JSP
une requête POST pour le second.
Modèle MVC : vue [JSP]
JSP > Servlet: Données issues du Client : les paramètres
Client HTTP Serveur
Récupération des paramètres par le serveur :
WEB
Si vous appelez à nouveau votre servlet depuis votre navigateur, en ajoutant
un paramètre nommé auteur à l'URL, par exemple :
Request
http://localhost:8080/test/FS?auteur=Mehdi

Controller
Alors vous observerez que le message affiché dans le navigateur contient
Requête
bien la valeur du paramètre précisé dans l'URL Servlet
HTTP

Response
Réponse

HTTP

Données params

Vue JSP
Modèle MVC : vue [JSP]
JSP > Servlet: Données issues du Client : les paramètres
Client HTTP Serveur
Récupération des paramètres par le serveur :
WEB
Nous pouvons très bien y accéder depuis notre page JSP sans passer par la
servlet, de la manière suivante :
Request
http://localhost:8080/test/Page.jsp?auteur=Mehdi

Controller
Requête

HTTP
Servlet
Response
Réponse

HTTP

Données params

Mais c'est une bonne pratique de toujours contrôler ce qu'on affiche au client

Vue JSP
Modèle MVC : vue [JSP]
Technologie JSP : Langage
Les bases du langage de la technologie JSP
1. Les balises
2. Les directives d’une page
1. Directives d’importation, d’inclusion et de définition
3. La portée ou visibilité des objets dans une page JSP
4. Les actions dites standard de la technologie JSP
5. Les expressions EL
Modèle MVC : vue [JSP]
Technologie JSP : Langage

Les Balises de bases Exemple

Balises de scriptlet : <% %>
Venant des des mots "script" et "servlet", à l’intérieure
d’une scriptlet se cache simplement du code Java.
Cette balise que nous avons déjà utilisée sert en effet à
inclure du code Java au sein de vos page JSP.

Boucle java pour remplir la liste de choix des jours

Modèle MVC : vue [JSP]
Technologie JSP : Langage

Les Balises de bases Exemple

Balises de déclaration : <%! %>
Scriptlet permettant de déclarer une variable ou une
méthode.
Il est possible d'effectuer plusieurs déclarations au sein
d'un même bloc

Déclaration d’une chaine et d’une méthode

Test d’appel à la méthode Inverser

.JSP
Modèle MVC : vue [JSP]
Technologie JSP : Langage
Les Balises de bases
Balises d’expression : <%= %>

C’est un raccourci de la scriptlet suivante :

Elle retourne le contenu d'une chaîne :

Balises de commentaire : <%-- --%>

Modèle MVC : vue [JSP]
Technologie JSP : Langage
Les directives JSP :
Les directives contrôlent comment le conteneur de servlets va gérer votre JSP.
Il en existe trois : taglib, page et include.
À travers les quelles on va pouvoir :
• Importer un package ;
• Inclure d'autres pages JSP ;
• Inclure des bibliothèques de balises (nous y reviendrons dans un prochain chapitre) ;
• Définir des propriétés et informations relatives à une page JSP.

Les directives sont comprises entre les balises <%@ et %>, 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.
Modèle MVC : vue [JSP]
Technologie JSP : Langage

Les directives JSP :

Directive taglib : <%@ taglib %>

Utilisé pour inclure et utiliser une bibliothèque personnalisée dans vos page JSP
Exemple d’inclusion d’une bibliothèque personnalisée nommée myLib avec un préfix ml

Directive page : <%@ page %>

Définit des informations relatives à la page JSP.

Exemple d’importation de deux classes Java :

Cette fonctionnalité n'est utile que si vous mettez en place du code Java dans votre JSP
puisque notre objectif est de faire disparaître le Java de nos vues, nous allons très vite
apprendre à nous en passer !
Modèle MVC : vue [JSP]
Technologie JSP : Langage

Les directives JSP :

Directive page : <%@ page %>
Il existe encore plus un ensemble des propriétés accessibles via cette directive page :

Exemple du pageEncoding. Qui s’ajoute automatiquement pour

spécifier l'encodage « UTF-8 »
Modèle MVC : vue [JSP]
Technologie JSP : Langage

Les directives JSP :

Directive page : <%@ page errorPage %> et <%@ page isErrorPage %>
Page.jsp error.jsp
Modèle MVC : vue [JSP]
Technologie JSP : Langage
<header / >

<article /
Les directives JSP :
Directive include : <%@ include %>

>
Nos vues correspondent rarement à une JSP constituée d'un seul bloc.
JSP <footer / >
Cela permet notamment de pouvoir réutiliser certains blocs dans
plusieurs vues différentes (ex. Les menus…)
Pour permettre un tel découpage, la technologie JSP met à votre
disposition une balise qui inclut le contenu d'un autre fichier dans le En pratique, il est très courant de découper
littéralement une page web en plusieurs fragments,
fichier courant.
qui sont ensuite rassemblés dans la page finale à
Via le code suivant par exemple, on peut inclure une feuille de style css interne destination de l'utilisateur.
dans notre page JSP. (mais cela pourrait très bien être une page HTML ou JSP ou
autre)
Modèle MVC : vue [JSP]
Technologie JSP : Langage
<header / >

<article /
Les directives JSP :
Directive include : <%@ include %>

>
La subtilité à retenir, c'est que cette directive ne doit être utilisée que pour inclure du contenu "statique" JSP <footer / >
dans votre page : i.e. headers ou le footers de la page, très souvent identiques sur l'intégralité des pages du
site.

Statique : l'inclusion est réalisée au moment de la compilation ;

Alors si le code du fichier est changé par la suite, les changements sur la page l'incluant n'auront lieu
qu'après une nouvelle compilation !

Cette directive peut être vue comme un simple copier-coller d'un fichier dans l'autre
Modèle MVC : vue [JSP]
Technologie JSP : Langage
<header / >
Les directives JSP :
Directive include : <%@ include %>

<article /
>
JSP <footer / >
Modèle MVC : vue [JSP]
Technologie JSP : Langage
Include dynamique avec Action standard :
Action standard include : <jsp: include page %>

Une autre balise d'inclusion dite "standard" existe, et permet d'inclure du contenu de manière "dynamique".
(après la compilation)
Le contenu sera ici chargé à l'exécution, et non à la compilation comme c'est le cas avec la directive
précédente :
Modèle MVC : vue [JSP]
Technologie JSP : Langage
Include dynamique avec Action standard :
Action standard include : <jsp: include page %>
Modèle MVC : vue [JSP]
Technologie JSP : Langage
Include dynamique avec Action standard :
Action standard include : <jsp: include page %>

Inconvénient : Ce type d’inclusion ne prend pas en compte les imports et inclusions faits dans la page réceptrice.

List.jsp Test.jsp output

Avec la directive include ça marche

très bien
Modèle MVC : vue [JSP]
Technologie JSP : Langage
Include dynamique avec Action standard :
Action standard include : <jsp: include page %>

Inconvénient : Ce type d’inclusion ne prend pas en compte les imports et inclusions faits dans la page réceptrice.

List.jsp Test.jsp output

Avec l’action standard include ça tient

pas compte des l’import

• Les pages incluses via la balise <jsp:include ... /> doivent en quelque sorte être "indépendantes" ; elles ne peuvent pas dépendre les unes des autres et
doivent pouvoir être compilées séparément.
• Ce n'est pas le cas des pages incluses via la directive <%@ include ... %>
Modèle MVC : vue [JSP]
Technologie JSP : Langage
La gestion des objets par la technologie JSP

L’un des concepts les plus importants qui intervient dans la gestion des objets par la technologie JSP est la portée des
objets ou visibilité, ou scope en anglais, qui définit tout simplement leur durée de vie.

Lors de la transmission de données de la servlet vers nos pages JSP, on a utilisé les attributs de requête.
Tels objets sont accessibles via l'objet HttpServletRequest, et ne sont visibles que durant le traitement d'une même
requête. Ils sont créés par le conteneur lors de la réception d'une requête HTTP, et disparaissent dès lors que le
traitement de la requête est terminé.

Du coup, on a donc créé, sans le savoir, des objets ayant pour portée la requête !
Modèle MVC : vue [JSP]
Technologie JSP : Langage
La gestion des objets par la technologie JSP
La portée des objets

Il existe au total quatre portées différentes dans une application JEE:

• page (JSP seulement) : les objets dans cette portée sont uniquement accessibles dans la page JSP en question ;
o JSP seulement veut dire qu’il n'est possible de créer et manipuler des objets de portée page que depuis une page JSP, ce
n'est pas possible via une servlet.
o Alors qu’il est possible de créer et manipuler des objets de portées requête, session ou application depuis une page JSP
ou depuis une servlet.
• requête : les objets dans cette portée sont uniquement accessibles durant l'existence de la requête en cours ;
• session : les objets dans cette portée sont accessibles durant l'existence de la session en cours ;
o Une session est l’objet associé à un utilisateur, elle existe tant qu’il utilise l'application, elle peut expirer lorsqu’il ferme
son navigateur, reste inactif trop longtemps, ou encore lorsqu'il se déconnecte.
o une session correspond en réalité à un navigateur particulier, plutôt qu'à un utilisateur.
• application : les objets dans cette portée sont accessibles durant toute l'existence de l'application.
Modèle MVC : vue [JSP]
Technologie JSP : Langage
La portée des objets
Pour visualiser bien le principe, voici un schéma regroupant les différentes portées existantes :

JSP Portée Page Portée Requête

Portée Page
JSP L’objet de portée requête est accessible durant
Portée Session
Requête le cheminement d'une requête
L’objet de portée
Client Nª1 Inclusion ou Portée Requête application est
redirection Et n'existe plus dès lors qu'une réponse accessible durant
Réponse est renvoyée au client ; toute l'existence
de l'application et
Portée Page par tous les
JSP clients.
un objet de portée page n'est
accessible que sur une page Portée
JSP donnée ;
application

Portée Page
Requête
JSP
Client Nª2 Inclusion ou Portée Requête
Réponse redirection
Portée Session
Portée Page L’objet de portée session est accessible durant
JSP l'intégralité de la visite d'un client donné.

JSP Portée Page Portée Requête

Modèle MVC : vue [JSP]
La portée des objets Exemple pratique

On envoi le string login comme paramètre de requête vers la servlet TestServlet

Login.jsp
Modèle MVC : vue [JSP]
La portée des objets Exemple pratique

On crée une session et on stocke le paramètre envoyé dans la session

TestServlet.java
Modèle MVC : vue [JSP]
La portée des objets Exemple pratique

On affiche la donnée du login stocké dans la session

Login.jsp

La valeur sauvgardé dans la session reste affiché

durant toute la session de l’utilisateur.
Vous pouvez tester en faisant un raffraichissemnt de
la page
Modèle MVC : vue [JSP]
La portée des objets Exemple pratique

Home.jsp On peut même tester avec une autre page accessible par cet utilisateur
Modèle MVC : le modèle [JavaBean]
JavaBean : Composant Réutilisable pour représenter les données
• un JavaBean désigne tout simplement un composant réutilisable. Client HTTP Serveur
• Il est construit selon certains standards des spécifications du langage Java
• un JavaBean n'a donc rien de spécifique au Java EE. WEB
• C’est un simple objet Java qui suit certaines contraintes :
o Paramétrable : un Bean est conçu pour être paramétrable à travers les "propriétés"
ou champs non publics présents dans un Bean (type primitif ou objets) Request

o Persistant : un Bean est conçu pour être sérialisable. La sérialisation est un

processus qui permet de sauvegarder l'état d’un Bean, et donne ainsi la possibilité Controller
de le restaurer par la suite. Ce mécanisme permet une persistance des données,
Requête
voire de l'application elle-même
HTTP
Servlet
o Réutilisable : un Bean est un composant conçu pour être réutilisable. Ne contenant
que des données ou du code métier, un tel composant n'a en effet pas de lien direct Response
avec la couche de présentation, ni avec la couche DAO, c'est cette indépendance qui Réponse
lui donne ce caractère réutilisable.
HTTP
o Dynamique : L'introspection est un processus qui permet de connaître le contenu
Données Modèle
d'un composant (attributs, méthodes) de manière dynamique, sans disposer de son
code source. C'est ce processus, couplé à certaines règles de normalisation, qui rend
possible une découverte et un paramétrage dynamique du Bean !

Vue JSP
Modèle MVC : le modèle [JavaBean]
JavaBean : Composant Réutilisable pour représenter les données

Sérialisation dans les application distribué

Modèle MVC : le modèle [JavaBean]
JavaBean : Composant Réutilisable pour représenter les données

Structure d’un JavaBean

• un JavaBean :
o doit être une classe publique ;
o doit avoir au moins un constructeur par défaut, public et sans
paramètres. Java l'ajoutera de lui-même si aucun constructeur
n'est explicité ;
o peut implémenter l'interface Serializable, il devient ainsi
persistant et son état peut être sauvegardé ;
o ne doit pas avoir de champs publics ;
o peut définir des propriétés (des champs non publics), qui
doivent être accessibles via des méthodes publiques getter et
setter, suivant des règles de nommage.
Modèle MVC : le modèle [JavaBean]
JavaBean : Composant Réutilisable pour représenter les données

Mise en place des JavaBean

• Afin de rendre vos objets accessibles à votre application, il faut que les
classes compilées à partir de vos fichiers sources soient placées dans un
dossier "classes", lui-même placé sous le répertoire /WEB-INF.
• Par défaut Eclipse, ne procède pas ainsi et envoie automatiquement vos
classes compilées dans un dossier nommé "build".
• Afin de changer ce comportement, il va falloir modifier le Build Path de
notre application.

• C'est ici qu'il faut préciser le chemin vers WEB-INF/classes afin que nos
classes, lors de leur compilation, soient automatiquement déposées dans
le dossier pris en compte par notre serveur d'applications.