Mini Projet JavaEE Master 2 NTDP Casa Maarif 2014-2015

Introduction

Le mini projet sera la continuation des TPs 3 et 4 avec quelques contraintes supplémentaires. Les mini projets se feront à trois, la date limite est le lundi 19 Janvier pour la venue de Mr Buffa à Casablanca, pour le cours Web 2.0/HTML5/JavaScript avancé. Vous lui rendrez le projet et ferez des démonstrations à cette occasion, le premier jour de la mission (le lundi). Aucun retard ne sera toléré.

Sujet

Un gestionnaire de compte bancaire comme le TP4 ou comme les corrections qui vous ont été remises du TP4. N'oubliez pas le fichier beans.xml au début du projet afin d'utiliser Context and Dependency Injection (CDI). Ajoutez la librairie CDI présente dans glassfish au projet comme dans les TPs.

Mais on demande des choses en plus:

1. On aura un modèle de données qui dit "on a des clients, chaque client peut avoir un ou plusieurs comptes bancaires, chaque compte est relié à la liste des opérations qui ont eu lieu sur le compte: type (création, débit, crédit, transfert, montant).
    
2. On aura au moins deux types de comptes bancaires, avec de l'héritage: compte courant, compte épargne qui rapporte de l'argent (avec un taux annuel et une méthode ajouteInterets() dans la classe entité CompteEpargne, autres (compte joint, facultatif...)
    
3. La base de données doit être remplie dès le déploiement, comme dans le TP3, avec un EJB singleton annoté par @Startup et une méthode appelée dès que le bean est instancié, avec @PostCreate, comme dans le TP3.
   • On veut au moins 50 clients et 500 comptes au démarrage, et quelques opérations pour chaque compte. Les tableaux affichés au démarrage doit être plein sur au moins 10 pages !!!!! Vous pourrez générer des données de manière aléatoire ou à l'aide du site web http://www.generatedata.com/
      
4. Facultatif mais très apprécié (des points en plus), on veut du Lazy Loading dans les datatables PrimeFaces. Comme dans le projet Goualmi par exemple.
    
5. L'application doit utiliser au moins un template avec un menu à gauche, un header en haut et le contenu principal au centre. Vous pouvez très bien utiliser plusieurs templates, ou des templates clients de templates, ou encore des templates de Primefaces, si vous en avez envie.
    
6. Gestion de login/password. Lorsque on se connecte pour la première fois sur l'application, on ne peut rien faire à part s'identifier, dans la partie "header" du template on aura un message invitant à s'identifier par login/password. Vous utiliserez pour cela un jsf managed bean avec @SessionScoped pour maintenir une propriété "connected", comme dans l'exemple JSFLoginPassword donné dans la page principale du cours. On utilisera des attributs "rendered=..." à divers endroits des pages xhtml pour afficher ou ne pas afficher du contenu si on est pas connecté.
    
7. Pour tranférer de l'argent ou retirer/déposer, on veut une solution ergonomique (on en veut pas taper l'id des comptes mais choisir dans le tableau ou dans une liste déroulante, comme dans le projet Goualmi correction du TP3/4). Primefaces propose plusieurs solutions.
    
8. Vous devrez utiliser au moins 5 composants primefaces non vus en cours, notamment ceux permettant d'afficher des messages de confirmation ou des messages d'erreur après chaque opération.
    
9. On distinguera le compte administrateur des comptes de clients ordinaires de la banque
   • L'administrateur peut créer, modifier, supprimer des clients et des comptes, il peut tout faire, ajouter de l'argent à n'importe quel compte en retirer, transférer de l'argent entre deux comptes quelconques, ajouter un compte à un client existant, etc. Il ne pourra supprimer un compte que si le solde est égal à 0
   • Un client ordinaire ne peut voir que ses propres comptes, il peut transférer de l'argent entre ses comptes. Ce n'est pas réaliste, mais il peut aussi déposer ou retirer de l'argent de ses comptes.
      
10. Facultatif : on ne peut retirer d'argent sur un compte épargne ; on peut seulement ajouter de l'argent et fermer le compte. Quand le compte est fermé, le client récupère l'argent qu'il a déposé plus les intérêts que le compte lui a rapporté et peut. A tout moment le client peut savoir combien il recevrait s'il fermait le compte. Pour tester cette fonctionnalité, implémentez une solution (click sur bouton, timer, p:poll primefaces, etc pour simuler un intérêt annuel toutes les 5s pour les comptes épargne.). Réfléchissez à comment vous pourriez implémenter cela (inteface utilisateur, choix du compte pour transférer l'argent du compte que l'on ferme, ou bien interdire de fermer un compte s'il n'a pas un solde à zéro, à vous de voir).
    
    
11. Facultatif: tester la portée@FlowScoped pour un JSF managed bean. Pour le transfert des comptes (et pour toutes les autres fonctionnalités), l'utilisateur n'aura pas à saisir l'id des comptes. Pour cela vous pourrez utiliser une nouveauté de JSF 2.2 non étudiée en cours, la portée "FlowScoped" : l'utilisateur choisi le compte source et le compte destination dans la liste de tous les comptes autorisés (ça en fait beaucoup pour l'administrateur) et le montant est donné ensuite. Cette portée est très utile. C'est le moment de montrer que vous savez aussi apprendre et utiliser des notions non vues en cours. Si vous essayez cette portée, dans la doc, indiquez quels sont les sites internet que vous avez utilisé.

Conseils

• Faites toujours un mini proto qui teste la base de donnés, puis qui la remplit. C'est la première chose à faire, bien avant de penser au projet Web. Je déploie je regarde que mes tables sont là et mes données aussi. On travaille en "drop and create" et remplissage des tables au déploiement tant qu'on a pas fini le projet à 99%
   
• Quand je rajoute une fonctionnalité je fais toujours dans cet ordre:
  1. Je modifie le modèle s'il y a besoin, et dans ce cas je modifie la génération des données de test s'il y a besoin. Je déploie et je vérifie que tout est ok.
  2. Je rajoute éventuellement des fonctionnalités dans les EJB sessions.
  3. Je modifie mes JSF backing beans ou j'en crée un nouveau, dans lequel je vais définir les propriétés/modèles qui serviront à l'affichage de valeurs ou à la saisie (je fais des getters/setters), j'écris les méthodes appelables par la vue.
  4. En dernier je fais la page XHTML. 
  5. Je teste au fur et à mesure, il ne faut surtout pas coder plein de trucs et tester un jour après.

Modalités de travail et de rendu

Il y a pas mal de choses à faire, mais vous êtes trois. Ne vous y prenez pas au dernier moment pour avoir un proto qui marche meme avec 5% des fonctionnalités. Il faut au moins que la base de données soit remplie tant que vous n'avez pas oublié comment ça marche :-)

IMPORTANT (rappel) : il est préférable de rendre une application qui fonctionne et qui est facile à utiliser, même si elle a peu de fonctionnalités, plutôt qu’une application qui a de nombreuses fonctionnalités mais qui n’est ni robuste, ni fiable, ni ergonomique.