|
Struts - Un framework MVC pour vos applications J2EE
1.2.Quelques rappels
Avant de commencer ce cours, quelques rappels sur les JSP/Servlets, les JavaBeans ainsi que les TagLib :
1.2.1.Des Servlets aux JSP
Lorsque l’on va développer un site Web à l’aide des technologies J2EE, on peut difficilement passer à côté des Servlets.
Une Servlet est une classe java chargée une seule et première fois par le moteur de Servlet (exemple : Tomcat) lors de son premier appel. Par la suite, on fera toujours appel à la même instance de cette Servlet.
Chaque fois que l’on va créer une Servlet, on créera une classe implémentant l’interface Servlet et donc redéfinir quelques méthodes dont les méthodes
- public void init(ServletConfig cfg) qui sera appelée lors du premier appel de la Servlet, lors de son instanciation.
- public void service(ServletRequest req, ServletResponse res) qui sera appelée à chaque appel de la Servlet instanciée.
- public void destroy() qui sera appelée juste avant la destruction de la Servlet.
Ainsi, c’est dans la méthode service() que va se trouver le code java dont le résultat, envoyé au browser, permettra l’affichage sur une page Web.
Le problème est que si l’on suit ce principe, la partie traitement de notre code est mêlée à la partie présentation alors que, comme il l’a été précisé précédemment, les bases même d’une application utilisant les technologies J2EE est le découpage en couches.
Pour séparer clairement la partie traitement de la partie présentation de notre application, on va donc utiliser les pages JSP.
Une page JSP ressemble à une page HTML pouvant contenir des balises JSP et/ou du code Java. Elle va donc nous permettre d’afficher les résultats des traitements effectués en arrière plan dans des classes Java. Dans ce cas, la page JSP va être convertie en Servlet puis le processus va être le même que pour une Servlet classique.
1.2.2.Dans la JSP : JavaBeans et TagLib
Dans notre page JSP, on va pouvoir utiliser différents composants pour afficher les différents résultats des traitements effectués dans les couches inférieures.
Les JavaBeans sont des composants qui vont permettre d’instancier et manipuler différents objets Java (à portée de la page, de requête, de session ou de l’application) à l’aide de balises JSP. L’avantage est que lorsqu’il va rencontrer une balise, le serveur va automatiquement détecter si l’instance de l’objet existe déjà ou non. Si c’est le cas, il reprend l’instance existante sinon il en crée une nouvelle. Cela va permettre d’utiliser un même objet sur plusieurs pages, voire tout le long de l’application.
Les TagLibs, tout comme les JavaBeans sont des composants qui vont permettre d’instancier et manipuler différents objets Java à l’aide de balises JSP. Cependant, ils ne pourront avoir qu’une portée limitée à la page courante. On ne pourra donc pas réutiliser une même instance d’un objet sur plusieurs pages. Pour chaque page de l’application, on aura une instance différente.
Les TagLibs, balises personnalisées, vont permettre, entre autres de créer ses propres balises de la plus simple à la plus complexe et ainsi d’afficher les résultats des différents traitements en quelques lignes.
Pour plus d’informations sur ces composants, n’hésitez pas à consulter le cours sur les Servlets/JSP.
1.2.3.Définition et intérêts d’un framework de présentation
On a donc pu voir que les JSP offrent une solution idéale pour afficher les résultats des traitements effectués en amont. Ils représentent la partie présentation de notre application. On a aussi vu que l’on pouvait utiliser les JavaBeans ou les TagLibs pour éviter d’avoir du code Java dans nos pages JSP.
Cependant, l’objectif premier d’un développeur est d’éviter de refaire chaque fois la même chose.
Pour cela, on va utiliser un framework qui impose une méthode de développement simple et efficace.
On va alors obtenir une application respectant les objectifs de réutilisabilité que vise la programmation orientée objet.
Concrètement, un framework est le squelette d’une application. Cela va permettre la création rapide d’actions/événements classiques, par exemple, un formulaire (tenant compte de la sécurité, de la validité, etc…).
Quels que soient les outils utilisés dans les couches inférieures, le framework de présentation choisi est complètement indépendant. Il nous permet donc d’atteindre l’objectif attendu ; des couches complètement indépendantes les unes des autres. On peut alors changer l’une des d’elles sans modifier les autres.
|
|
 |
