Cours Spring MVC par l’exemple – Partie 3

……..

Rappels

Nous poursuivons dans cet article le travail fait dans les précédents :
• Spring MVC par l’exemple – partie 1 : [http://tahe.developpez.com/java/springmvc-part1]
• Spring MVC par l’exemple – partie 2 : [http://tahe.developpez.com/java/springmvc-part2]
1. le client fait une demande au contrôleur. Celui-ci voit passer toutes les demandes des clients. C’est la porte d’entrée de l’application. C’est le C de MVC. Ici le contrôleur est assuré par une servlet générique :
org.springframework.web.servlet.DispatcherServlet
2. le contrôleur principal [DispatcherServlet] fait exécuter l’action demandée par l’utilisateur par une classe implémentant  l’interface:
org.springframework.web.servlet.mvc.Controller
3. le contrôleur [Controller] traite une demande particulière de l’utilisateur. Pour ce faire, il peut avoir besoin de l’aide de la couche métier. Une fois la demande du client traitée, celle-ci peut appeler diverses réponses. Un exemple classique est :
• une page d’erreurs si la demande n’a pu être traitée correctement
• une page de confirmation sinon

 Encore des contrôleurs

Revenons sur le schéma de base d’une architecture Spring MVC :
Au cours de l’étape 2, la requête [HttpRequest] du client va être traitée par les différents modules placés entre le contrôleur général [DispatcherServlet] et le contrôleur particulier [Controller] qui doit traiter la demande du client. Nous nous proposons ici de présenter de nouveaux objets [Controller].

Le contrôleur ParameterizableViewController

L’interface [Controller] est la suivante :
Parmi les classes implémentant cette interface, on voit ci-dessus, la classe [ParameterizableViewController]. Ce contrôleur ne fait aucun travail sur la requête qu’il reçoit. Il se contente de déterminer la vue qui doit être affichée. Celui-ci est généralement fixé par configuration. Le contrôleur [ParameterizableViewController] ne construit aucun modèle pour la vue qu’il demande d’afficher. Celle-ci doit donc récupérer son modèle, si elle en a un, dans les différents contextes de l’application : requête,  session, application.
Le contrôleur UrlFileNameViewController
Revenons sur l’interface [Controller] :
Parmi les classes implémentant cette interface, on voit ci-dessus, la classe [UrlFileNameViewController]. Ce contrôleur est trèssemblable au contrôleur [ParameterizableViewController] si ce n’est que le nom de la vue à afficher est extrait du dernierélément de l’url demandée, plutôt que défini dans un fichier de configuration. Ainsi si l’URL demandée est de la forme[http://machine:port/elmt1/elmt2/…/elmtn.xxx], le nom de la vue sera elmtn. A ce nom, peuvent être ajoutés un préfixe et unsuffixe qui, eux, sont définis par configuration.
Le contrôleur MultiActionController
Présentation
Revenons sur l’interface [Controller] :
Parmi les classes implémentant cette interface, on voit ci-dessus, la classe [MultiActionController]. Cette classe permet de traiter des requêtes différentes avec un unique contrôleur. Qu’entend-on par requêtes différentes ? Une requête est de la forme [/url?param1=val1&param2=val2&….]. [MultiActionController] distingue deux requêtes soit par la composante [url], soit par l’un des paramètres [parami] qui sert de marqueur de requête.
La classe [MultiActionController] est une classe abstraite destinée à être dérivée. Sa lignée est la suivante :
[MultiActionController] dérive de la classe abstraite [AbstractController], classe parent d’un certain nombre d’autres contrôleurs prédéfinis de Spring MVC. Pour qu’elle soit vraiment utile, il faut la dériver. Pour faciliter l’explication qui va suivre, appelons [MyMultiActionController], une classe dérivée de [MultiActionController].
Deux requêtes différentes [req1] et [req2] seront traitées par deux méthodes différentes du contrôleur [MyMultiActionController]. Celles-ci ont la signature suivante :
Exemple 2 (spring-mvc-33B)
Nous reprenons l’exemple précédent dans un nouveau projet Eclipse (spring-mvc-33B). Celui-ci est identique au projet (springmvc-33)
mais nous utilisons une autre stratégie de résolution de noms de méthodes.
La page [list.jsp] est modifiée comme suit :
1. <%@ page language=”java” pageEncoding=”ISO-8859-1″ contentType=”text/html;charset=ISO-8859-1″%>
2. <%@ taglib uri=”/WEB-INF/c.tld” prefix=”c” %>
3. <%@ page isELIgnored=”false” %>
4.
5. <html>
6. <head>
7. <title>Spring(mvc-33B)</title>
8. </head>
9. <body>
10. <h3>MultiActionController (B)</h3>
11. <form method=”post”>
12. …
13. <input type=”submit” name=”delete” value=”Supprimer”>
14. …
15. <input type=”submit” name=”add” value=”Ajouter”>
16. …
17. </form>
18. </body>
19. </html>

………
Cours pdf

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *