Java Serveur App 5 : Navigation

Navigation


La navigation, c'est principalement la manière dont notre application gère le passage d'une page à une autre tout en permettant l'exécution de code Java entre elles. Nous allons voir comment permettre certains bons points:

• comment rendre les pages inaccessibles directement
• comment en contrôler l'accès via le contrôleur et exécuter du code Java
• comment conserver des URLs propres au cours de la navigation

WEB-INF et les pages cachées

Pour cacher une page JSP ou toute autre resource, il suffit de placer dans le répertoire WEB-INF. Pour tester, déplacer une de vos pages JSP dans WEB-INF. Essayez d’y accéder avec l’URL (dans mon cas, j'ai déplacé le fichier commande.jsp):

http://localhost:7070/WEB-INF/commande.jsp

Vous devriez alors obtenir une erreur 404.

Accéder aux pages cachées via le contrôleur

Dans le contrôleur, nous allons pouvoir utiliser une instruction du type:

request.getRequestDispatcher("WEB-INF/commande.jsp").forward(request, response);

Cette redirection se fait au niveau du serveur et permet d’accéder aux pages contenues dans le WEB-INF. Nous allons modifier le doGet introduit précédemment:

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) 
  throws ServletException, IOException  {
 // get the URL pattern, the action
 String action = request.getServletPath();
 if (action.equals("/motif")){
  System.out.println("Controler GET motif ");
  return;
 }
 if (action.equals("/acheter")){
  System.out.println("Controler GET acheter ");
  request.getRequestDispatcher("WEB-INF/commande.jsp").forward(request, response);
  return;
 }
}

Maintenant, vous devriez pouvoir accéder à votre page JSP via l'URL : http://localhost:7070/acheter

Redirections vers des JSP


Notre contrôleur va pouvoir rediriger sa requête de deux manières différentes: 

• response.sendRedirect("url de redirection");
• request.getRequestDispatcher("url").forward(request,response); que nous venons de voir.

Voyons un peu quelles sont les différences ...

Redirections par sendRedirect


Une redirection par sendRedirect est effectuée via la réponse HTTP. Les événements sont donc les suivants:

1. La servlet reçoit la requête du navigateur
2. La servlet répond avec sa réponse qui contient une demande de redirection vers une url
3. Le navigateur envoie une nouvelle requête au serveur sur cette URL (et donc potentiellement repasse par le contrôleur).

Les conséquences sont les suivantes:

• L'URL en question doit être accessible du navigateur
• La redirection change l'URL visible dans le navigateur
• Provoque un nouveau cycle requête/réponse HTTP
• Les paramètres de la première requête HTTP sont perdus pour la seconde requête (sauf si vous les avez spécifiés dans l'URL de redirection en méthode GET)

Redirections par forward


L'accès au RequestDispatcher permet d'accéder à des URLs serveur comme des pages JSP contenues dans le répertoire WEB-INF. D'un navigateur, les fichiers contenus dans le répertoire WEB-INF de votre webapp ne sont pas accessibles. Par contre, on pourra effectuer une redirection du type suivant:

request.getRequestDispatcher("WEB-INF/page.jsp").forward(request,response);

Ici, le RequestDispatcher (qui est un objet du serveur) va faire suivre à la "page.jsp" en lui passant la requête et la réponse initiales. C'est page.jsp qui produire la réponse HTTP.

En conséquence:

• On peut cacher une page "WEB-INF/rep/sous-rep/page.jsp" avec un URL pattern plus propre "/commande", l'URL n'est pas réécrite dans la barre d'adresses du navigateur
• Les pages JSP ne sont pas directement accessible ce qui permet d'effectuer des vérifications en Java, des accès BD etc. dans le contrôleur avant d'afficher la page JSP.
• Les paramètres initiaux sont envoyés à la page JSP.

Vues + contrôleur : un mot sur MVC

Voici une première version d'une approche MVC web :

• Chaque action, clique sur un bouton, envoi de formulaire référence un motif URL (ex: "/payer")
• Chaque motif URL pointe sur le contrôleur, une servlet en Java.
• Dans le code Java, on valide que les paramètres sont corrects, on lit ou on écrit en base de données ce qui est nécessaire au modèle, on écrit dans la session les informations nécessaire etc.
• Une fois les traitements effectués, on redirige vers une vue JSP qui va afficher les informations nécessaires prises dans les attributs de la requête ou de la session.
• Cette vue, qui finalement génère une page HTML peut contenir des liens ou des boutons qui à leur tour pointe vers des motifs URL et provoquent des actions qui déclencheront un passage dans le contrôleur.

On peut donc implanter une bonne part de l'application sans le modèle en s'assurant que les liens entre page donnent bien lieu à un passage dans le contrôleur. Cet ensemble Vues + contrôleur permet d'implanter la navigation dans notre application.

Résumé

Nous avons maintenant un squelette d’application Vues + Contrôleur. Pour avoir un squelette MVC, il ne nous manque plus que le modèle (de données).

Fichiers

Le projet que vous trouverez ici contient maintenant un contrôleur et quelques motifs URL. 
Pour compléter la navigation de votre application (pas de M)VC, il suffit de:

• Intégrer toutes les actions que votre utilisateur peut déclencher (voirMaCommande, entrerCoordonnees, payerCommande, voirMenu, voirRestaurants etc.) dans votre web.xml. 
• Compléter votre contrôleur pour avoir un bloc dédié dans le doXXX approprié (GET ou POST) pour chaque action.
• Rediriger vers la vue JSP correspondante de votre application.