Projet J2EE d' eCommerce

Document Sample
Projet J2EE d' eCommerce Powered By Docstoc
					Projet J2EE d' eCommerce
        rapport de projet 2006-2007
           Jounayd Id Salah
   I. Présentation du projet
   II. Client
       1. Quelques points
       2. Vues
   III.Administration
       1. Quelques points
       2. Vues
   IV. Technologies
   V. Installation
   VI. Organisation
   VII.Conclusion

I Présentation du projet
Voir sujet

LES DIAGRAMMES DE CLASSE SONT DISPONIBLES DANS LE DOSSIER :
./UML
(leur taille les rendrait illlisibles dans le pdf)
II Client
   1. Quelques points

       - interface dynamique :
               - drag & drop des produits sur l'icône du panier
                - quelques animations
                - raffraichissement des sous pages (partie blanche) au lieu de l'ensemble de la page
                web.
                - cookies pour assurer une sauvegarde sur le long terme des données clientes.

   2. Capture d'écran
3. Vues
III Administration
   1. Quelques points

        - un magasin par produit uniquement
        - properties pour sauvegarder des variables d'environnement globales.
        Les properties sont des variables d'environnement globales sauvegardées par des EJB dans
la base de données. Le format est générique (mais pas complet encore).
        - upload de fichiers (icône du produit).

   2. Capture d'écran




   3. Vues
IV Technologies
 1. AJAX

   Au début, utilisation de la lib rico basée sur prototype. Rico n'étant finalement qu'une
   arnaque et après les problèmes de compatibilité et de « patching » des nouvelles versions de
   prototype, et particulièrement l'absence de « form » et ...., utilisation directe de prototype.
   Un intérêt de rico était pourtant de pouvoir modifier plusieurs objets en une seule réponse
   (les éléments de l'ajax-response), il faut multiplier les requêtes avec prototype. Quelques
   bonnes idées donc, mais impossibilités d'accéder à certaines fonctionnalités de prototype
   (eval, forms).
   Scriptaculous est utilisé pour les effets plus graphiques. Il s'avère très simple d'utilisation,
   mais j'ai rencontré quelques bugs dû à des « incompatibilités » des paramètres CSS et
   d'utilisation non conventionnel. (j'ai utilisé un effet de déroulement des descriptions au
   passage de la souris, mais si on gesticule trop rapidement, on bloquait l'animation et les
   descriptions devenaient alors inaccessibles).
   Conclusion : simplicité d'utilisation dans tous les cas, mais gros problèmes de stabilité et
   compatibilité.

 2. Upload

   Je n'arrive toujours pas à comprendre pourquoi la gestion des uploads n'est pas mieux
   intégrée dans les technologies servlet distribuées par java. Une bibliothèque supplémentaire
       a été utilisée (uploadbean.jar et dépendances : struts.jar, ... ). Bizarement, celle ci est sensée
       s'avérer complète, mais j'ai remarqué déjà de nombreuses limitations, pourtant dues à des
       procédures de téléchargement assez classiques.

   3. CSS

       Il manque clairement un switch de choix de navigateur quand il y a des problèmes de
       compatibilités. Il serait intéressant d'avoir une sorte de précompilateur comme dans le C
       avec ses directives conditionnelles. Il serait aussi intéressant d'utiliser un système de macros
       pour alléger le code et éviter les nombreux héritages si on veut factoriser le code.
       Aucune validation n'a été faite tout comme le XHTML.

   4. EJB / Servlets

       no comment. Je ne connais pas du tout les autres technologies comme struts ou autres.
       J'aurais bien aimé développer avec EJB 3.0, pour « coder » un bean au lieu d'écrire sa classe
       puis le paramétrer au travers d'un fichier de configuration. Je serais curieux de savoir s'il est
       possible d'ajouter une forme d'abstraction supplémentaire par rapport au fonctionnement
       pour n'avoir qu'à coder les méthodes métier et autres finders. On perd vraiment trop de
       temps à coder du code de fonctionnement EJB (je compare à l'écriture d'une simple classe
       dont le temps est négligeable).
       Un autre problème vient du fait que les erreurs que l'on rencontre sont difficilement
       compréhensibles. Il serait intéressant d'avoir un outil spécialisé donnant des informations
       non conventionnelles supplémentaires pour chaque erreur comme :
           - les erreurs types de programmation (basées sur une base de données d'expériences
           online, ainsi une erreur rencontrée une fois aiderait à la résolution de celles d'autres
           développeurs utilisant aussi ce même service). La démarche actuelle étant de passer des
           heures à chercher à la fois dans le code et sur google.
           - des exemples de code correct classique en fonction du contexte.
           - des biscuits au chocolat pour remonter le moral.

V Installation
Un fichier README.txt est disponible dans le répertoire principal pour détailler les instructions
d'installation.
VI Organisation

    1. Outils Utilisés

–   CVS : SVN prévu pour les futurs projets, mais pour l'instant le CVS était en place, alors c'est ce
    qui a été utilisé.(bien entendu tortoise et winmerge pour un CVS plus graphique sous windoz)
–   Task manager : utilisé au début (cf l'image), mais rapidement abandonné pour cause de ghosting
    aigu. Permet d'avoir une organisation dans l'esprit Xtreme programming
–   Fiddler : logiciel windoz pour intercepter les flux http (utile pour les réponses ajax).
–   Eclipse + Lomboz : environnement de développement xml + jsp + java
–   Eclipse + eclipseUML : génération des annotations et du UML correspondant au code.
–   SmartDraw : diagrammes des vues.


    2. Problèmes rencontrés

 Une démarche réellement incrémentale a été décidée dès le départ afin d'éviter d'avoir à se battre
contre les xml. Par contre contrairement à la proposition d'un des profs, l'Ajax a été inclus dès le
départ afin de simplifier le diagramme des vues plutôt que d'avoir à tout réécrire par la suite.

–   Upload : Problème de visibilité de la lib utilisée (uploadbean.jar et autres bibliotèques
    dépendantes) à l'intérieur des servlets. Le code a été déplacé sur la jsp correspondante au grand
    malheur du MVC.
–   Gros problèmes de compatibilité entre les versions des libs AJAX.(rico et prototype
    particulièrement). Ces libs sont comme le reste du développement web, totalement instables dès
    qu'on s'écarte de l'utilisation classique ou du domaine de compatibilité.
–   Debug avec ejb, ça existe ?
–   Beaucoup de temps de perdu pour un résultat très simple : problèmes de complexité des EJB et
    de compatibilité des technologies web (CSS 'et' AJAX)
–   Beaucoup de bugs CVS, notamment sur les update. Je n'ai jamais eu ce genre de problèmes avec
    sourceforge auparavant (les problèmes arrivent sur les machines de l'n7).
–   Problème de transparence des png avec IE (corrigé dans la version 7). Normalement j'utilise un
    script javascript qui fonctionne au chargement initial de la page, mais il y a un
    disfonctionnement et les png restent opaques. Le gif n'est pas une alternative puisqu'elle utilise
    une couleur pour définir sa transparence. Cela limite le gif à des images rectangulaires qui
    n'auront pas à souffrir d'un aliasing de transparence. Pour les versions inférieures à la 7, il faut
    « magouiller » en fonction des circonstances.
–   Problèmes de session partiellement résolus : augmentation de la durée de la session à un mois et
    autres « magouilles ». Je ne suis pas satisfait de la solution, j'ai essayé de trouver des exemples,
    mais rien de vraiment distinguable.

VII Conclusion

Projet intéressant même si je ne me sens pas concerné mais trop de problèmes liés aux technologies.
Une des vertues des informaticiens est de savoir s'adapter, ... mais des fois ça dépasse les bornes.
Les technologies que j'ai survolées sont surement indispensables et « ergonomiques » en un sens,
mais leur utilisation relève du parcours du combattant.
Je me suis toujours posé la question sur les ejb, vu le taux d'erreurs pour des choses très simples de
leur fiabilité et s'il était nécessaire de faire des tests intensifs pour garantir un code stable et fiable
(sans parler de tout ce qui est web (servlets, jsp, css, etc...).
Je ne sais pas si des outils existent pour « modéliser » les EJB, piloter les EJB par diagrammes et
écrire le code métier uniquement au lieu d'écrire le code complet de fonctionnement EJB.