Accueil > Intranet Michel Buffa > Technologies Web, Master 1 Miage, 2012-2013 > TP3 M1 Miage applications web, 2012-2013

TP3 M1 Miage applications web, 2012-2013

De $1

Introduction

Dans ce TP nous allons intégrer au TP1 des éléments vus lors des derniers cours et TPs.

Gestion de login/passwords en Ajax

Lors du dernier TP sur jQuery vous avez testé un petit bout de code qui permet de gérer les logins/passwords en Ajax.

Intégrer simplement l'exemple du dernier TP sur jQuery

Dans un premier temps vous allez juste intégrer bêtement cet exemple dans le code de votre TP. Ajoutez le formulaire de saisie + le code Javascript dans la partie "en-tête" de votre application (le bandeau en haut de la page), Créez une servlet ServletLogin comme dans le TP précédent, vérifiez que cela fonctionne.

Ajouter un objet dans la session HTTP pour indiquer qu'on est bien connecté

Maintenant, on va modifier la ServeltLogin pour insérer dans la session HTTP un objet qui indique que l'utilisateur est connecté, s'il s'est bien authentifié, vous vous inspirerez de l'exemple donné dans le support de cours sur les pages JSPs (pages 28 et 29).

Modification de toutes les Servlets pour qu'elles ne fassent rien tant qu'on est pas connecté

Si on invoque n'importe quelle autre Servlet du projet, elles ne doivent rien faire si on est pas connecté.

Modification de la JSP principale pour qu'elle affiche un message si on est pas connecté

Là aussi, si on demande l'affichage d'une page du projet (soit directement en tapant l'adresse de la JSP dans le navigateur, soit par un forwad() depuis une Servlet), dans le cas où l'utilisateur n'est pas connecté, un message "vous devez vous identifier" doit apparaitre dans la page principale.

Par la suite, toute Servlet ou toute page JSP devra vérifier l'état "connecté" de l'utilisateur

Et oui, si votre projet comprends 10 Servlets et 15 pages JSPs, il n'est pas question qu'un utilisateur non identifié puisse exécuter du code en entrant directement un URL dans le navigateur. Seules les pages "publiques", pouvant être vues sans être forcément authentifié, n'ont pas besoin de faire cette vérification.

Ajout d'un panier pour acheter des livres

On va modifier le projet pour pouvoir acheter des livres. Pour cela on va créer un modèle "Panier". On ne se préoccupera pas pour l'instant de la persistence du panier dans une base de données, on gèrera la liste des livres mis dans le panier uniquement en mémoire, à l'aide d'une collection. Souvent d'ailleurs, dans les sites de e-commerce, les paniers ne sont pas persistants (les commandes, en revanche le sont... ce sont juste des "paniers validés" avec quelques informations supplémentaires.

Modèlisez un panier

Un panier n'est rien d'autre qu'une liste de couples Livre/Quantité. Par exemple je peux acheter 1 exemplaire du livre A et 2 exemplaires du livre B. Ecrivez la classe Panier.java (vous aurez sans doute besoin d'une classe en plus pour décrire le couple Livre/Quantité, je propose de l'appeler LivreQuantite.java). Un Panier est donc une ArrayList d'instances de cette classe LivreQuantite.

Ajoutez des méthodes :

  • AddBook(int quantite, Book livre)
  • getBooks() qui renvoie une Collection de couples LivreQuantite
  • getPrixTotal() qui renvoie le prix total

Pourquoi pas de "gestionnaireDePanier" ?

Et bien parceque on aura un panier et un seul par personne connectée. A-t-on besoin de "rechercher un panier" ? De "lister tous les paniers ?" etc. Non, le panier est unique pour chaque client. Les méthode dans le modèle suffiront donc pour "le gèrer". 

Quelle durée de vie pour le panier ?

D'après vous ? Un panier a la même durée de vie que la session HTTP ! Le panier va "exister" lorsqu'on passera d'une page du site à l'autre, etc. son contenu ne doit pas être perdu. La logique voudrait qu'on utilise l'annotation @SessionScoped, équivalent de @ApplicationScoped mais qui donne une durée de vie égale à la session. Pour le moment on ne va rien mettre comme annotation de durée de vie, car vous verrez qu'on ne peut pas injecter un @SessionScoped depuis une Servlet, car la Servlet étant ré-entrante, il n'en existe qu'une seule instance pour tous les utilisateurs.

Si on injecte un panier dans une Servlet, il sera injecté lors de la création de la Servlet, une et une seule fois. Ce sera le même panier pour tout le monde, ce que nous ne voulons pas. Pour le moment, on créera le panier avec un "new" quand on en aura besoin. Plus d'informations seront données en cours.

Ajout d'un lien dans la table des livres pour l'ajouter au panier

Vous ajouterez un lien dans une colonne supplémentaire de la table d'affichage des livres, intitulé "ajouter au panier". Ce lien pointera par exemple sur ServletPanier?action=ajouterLivre&id=3 ou id vaut l'id du livre.

Ecriture d'une Servlet pour gérer le panier

Cette Servlet va devoir faire plusieurs choses : 

  1. Vérifier qu'on est bien connecté, comme vu en début de TP.
  2. Si on est connecté, regarder si il existe un panier dans la session,
  3. Si il existe un panier alors on le récupère pour travailler avec : Panier p = session.getAttribute("panier"); p.addLivre(....) etc.
  4. Si il n'y a pas de panier dans la session, en créer un (avec un "new") et le mettre dans la session : if(p == null) { p = new Panier(); session.setAttribute("panier", p);....}

Cette servlet devra gérer les actions ajouterLivre, listerContenuDuPanier, etc. Et rediriger vers les bonnes pages JSPs. Il faudra notamment une page afficherContenuPanier.jsp qui affiche un tableau avec le contenu du panier.

Ajout d'une Commande et d'un GestionnaireDeCommande

Maintenant on va ajouter au projet un bouton "passer la commande" en bas de l'affichage du panier, qui va "valider la commande".

Alors, tout d'abord c'est quoi une commande ? 

On peut modéliser de plusieurs manières mais je propose :

  • Une commande contient le nom, l'email et l'adresse du client (pour le moment, sous forme de chaines de caractères)
  • Elle comprend la date du jour,
  • Elle comprend la liste des produits commandés : la quantité et la référence des produits (ah, mais dites donc, c'est un panier ça !)
  • Elle a un prix total.
  • Autres : état, etc...

Elle possède des méthodes set/get pour tous ces attributs.

Un gestionnaire de commandes

On peut avoir de nombreuses commandes, on veut pouvoir rechercher des commandes, sauvegarder/valider des commandes, etc. donc il faut un gestionnaire.

Inspirez-vous du TP1 pour écrire tout d'abord un gestionnaire de commandes qui fonctionne en mémoire. Vous l'associerez à une Servlet pour gérer les commandes, à des pages JSPs pour afficher le contenu d'une commande, pour visualiser toutes les commandes, etc.

Pour aller plus loin...

Bon, il est clair qu'en termes de modélisation de données, on aurait envie de faire plusieurs choses:

  • Rendre les commandes persistentes dans une base de données,
  • Avoir une relation entre la table des clients et la table des commandes (1 client, n commandes), entre la table des commandes et la table des Livres, etc.
  • Gérer les stocks
  • Etc.

Pour les prochains TPs, on abandonne JDBC, on va passer à JPA et aux EJBs, vous verrez qu'on peut faire tout ceci beaucoup plus simplement et efficacement que' si on devait tout coder en JDBC/classes java normales.

 

 

 

 

Mots clés:
 
Images (0)
 
Commentaires (0)
Vous devez être connecté pour poster un commentaire.