Outil de C.M.S. sur la plateforme Seam

Transcription

1 UNIVERSITE DE MONTPELLIER II Outil de C.M.S. sur la plateforme Seam Travail D Etude et de Recherche effectué dans le cadre du master informatique 2ème année spécialité Génie Logiciel à la faculté des Sciences de l Université de Montpellier II. Année 2008/2009 Réalisé par AHAMADA Soulé, DUVAL Simon, et KEIRA Mamadou Encadrants : M. DONY Christophe M. CHATEL Thierry, directeur de projet Chez IOcean

2 Sommaire 1. Introduction Méthodologie de travail Gestion des ressources Gestion de projet Planning prévisionnel Outil de collaboration et de gestion version : SVN Technologies utilisées et concepts Framework Seam Le modèle de composant Seam Contextes Seam Inversion de contrôle et injection de dépendances Gestion des conversations Intégration avec JPA Framework Hibernate Framework JSF, Facelets Composants RichFaces Configuration de l environnement de développement Serveur d application Tomcat Configuration Hibernate Mise en œuvre et réalisation Diagrammes des cas d utilisation Back end Front end Implémentation du contenu Gestion des droits d utilisateurs Contrainte sur l'implémentation des utilisateurs Solution adoptée modification à effectuer pour l'adaptation Gestion des droits Implémentation des droits Comment gérer les droits? Qui affecte les droits aux utilisateurs? Conséquence des droits sur le contenu

3 5.4. Templates de pages web Gestion des exceptions Conclusion Apports personnels Apports pour IOCEAN Perspectives Annexes Bibliographie

4 1. Introduction Dans le cadre de notre formation visant à obtenir le diplôme de Master informatique à vocation professionnel, nous avons effectué ce T.E.R. (Travail d Etude et de Recherche) dont l objectif initial était de concevoir un système de gestion de contenu, plus communément appelé CMS (Content Management System). Ce dernier est définit, selon Wikipédia, comme «une famille de logiciels destinés à la conception et à la mise à jour dynamique de site web ou d'application multimédia». En collaboration avec IOcean, entreprise située à Montpellier, nous avons déterminé le besoin fonctionnel du T.E.R.: Une première partie «arrière-boutique», que l on appellera par la suite «Back Office», concernera l administration et la gestion du site (gestion du contenu, publication, gestion des utilisateurs et des droits, etc.) ; Une seconde partie, correspondant à l interface de l application que nous appellerons par la suite Front Office, affichera le contenu consultable. Il est important de noter qu il existe déjà un grand nombre d implémentations de systèmes de gestion de contenu. L objectif du T.E.R. n est donc pas de créer une implémentation de plus, mais bien d apporter de nouvelles idées. Celles-ci porteront sur la manière de gérer le contenu, les utilisateurs et les droits qu auront ces derniers sur le contenu. L application a été développée sur la plateforme JBoss Seam. Elle implémente les fonctionnalités principales que requièrent un CMS et, évidemment, nos propres idées. Certaines fonctionnalités qui n ont pas été implémentées en raison du temps impartie au T.E.R. seront tout de même expliquées. Ce rapport vous informera, dans un premier temps, sur la méthode de travail utilisée, ainsi que la gestion du projet en général ; dans un deuxième temps nous présenterons l analyse en expliquant le choix des solutions retenues ainsi que celles délaissées ; nous continuerons sur la conception et l implémentation du logiciel en pointant notre documentation et explication sur le fonctionnement de la gestion du contenu et des droits utilisateurs. Pour finir nous établirons un bilan sur le résultat obtenu, sur les difficultés rencontrées, et sur l apport personnel de ce T.E.R. 4

5 2. Méthodologie de travail 2.1. Gestion des ressources Notre groupe de T.E.R. est composé de 4 membres : Ahamada Soulé, Duval Simon, Keira Mamadou et Touil Mehdi. Ce dernier n'a pu participer à la réalisation de ce projet du à des problèmes de santé. Lors de notre première réunion nous avons décidé de gérer ensemble la partie analyse. Il nous semblait important que chacun puisse, d une part, apporter des idées sur l architecture du projet et, d autre part, avoir une vue d ensemble sur la solution retenu pour la réalisation du projet. Ensuite, pour la partie conception et la rédaction de ce rapport, nous avons préféré nous partager le travail de manière à progresser plus rapidement dans la réalisation et que chacun puisse participer à toutes les phases du projet de manière verticale Gestion de projet Après la lecture du cahier des charges, lors de l analyse, nous avons effectué le découpage du projet et conçut une planification prévisionnelle du projet à l'aide de l'outil Gantt (Figure 1) en tenant compte des ressources et du temps disponible. Ce planning nous a servi essentiellement au respect des délais Planning prévisionnel 5

6 Figure 1 : Planning prévisionnel Tout d abord, nous avons distingué cinq tâches importantes que sont l étude préalable, la gestion du contenu, la gestion des droits utilisateurs, la réalisation des templates et l intégration des parties Back End et Front-End. L étude préalable : Cette première partie nous a permis d étudier les besoins du client (l entreprise IOcean) et par la suite de concevoir un diagramme de cas d utilisation correspondant à une solution plausible au besoin. Enfin, nous avons déterminé les outils nécessaires à la réalisation du projet (voir environnement Technique). Gestion du Contenu et Gestion des droits des utilisateurs: Ces deux parties ont été réalisées avec la même démarche. Tout d abord nous avons effectué la conception de la partie métier (diagramme de classes, implémentation et tests), ensuite la création de la base de donnée et des tables nécessaires, et enfin nous avons développé l interfaces (Vues JSF). Les templates : Nous devions réaliser des templates pour permettre au client d adapter notre réalisation en fonction de son application spécifique. Cette partie correspond à la création de composants Intégration : Par intégration, nous regroupons les tâches suivantes : l adaptation 6

7 de la partie front-end à la partie back-end, la revue de code, l ajout de commentaire, la correction de bug Outil de collaboration et de gestion version : SVN Nous avons mis en place un Wiki avec Google code. En utilisant cette plateforme, nous avons pu partager des informations sur le projet ainsi que le code source grâce au SVN intégré de Google Code. 3. Technologies utilisées et concepts 3.1. Framework Seam Seam agit comme un chef d orchestre : les vues JSF (pages web ou portions de pages web) accèdent aux composants applicatifs par l intermédiaire de Seam. les composants applicatifs accèdent à d autres composants applicatifs par l intermédiaire de Seam. les composants applicatifs accèdent aux entités persistantes du modèle via le contexte. Le développement d application web sur la plateforme Seam passe par la création d un fichier pages.xml qui permet entre autre : La définition d une page de redirection en cas d interruption de la conversation ; La définition des règles de navigation entre les pages JSF, on peut faire des redirections après une action sur composant Seam ; L interception des exceptions se produisant à l extérieur du contexte d un composant ; La restriction d accès à certaines pages de l application selon des conditions spécifiées. Par exemple dans notre l application, l accès à la partie administration est réservé aux personnes ayant un accès et authentifié comme le montre le listing de code ci-dessous : <page view-id="/admin.xhtml" login-required="true"> <restrict>#{sessionutilisateur.utilisateur.accesbackend}</restrict> Le <restrict>#{authentification.authentification()}</restrict> modèle de composant Seam </page> A l'origine le modèle de composants de Seam a été conçu pour permettre l'intégration directe entre JSF et les EJB3. Quand on développe une application web à partir de JSF, on implémente généralement deux types de composants : une page JSF qui va constituer la vue et contenir le code HTML, une classe Java appelée backing Bean JSF qui va constituer le modèle et fournir les méthodes pour implémenter les actions utilisateurs (soumission formulaire...). Les méthodes du backing Bean JSF liées aux actions utilisateurs accèdent en général à un composant métier. Si celui-ci est déployé sous la forme d'un EJB 3 de type Session Bean, il 7

8 est alors nécessaire d'implémenter une couche d'adaptation entre ces deux types de composants. Figure 2 : Intégration JSF/EJB 3 sans le Framework Seam Avec Seam, il n'y a plus de distinction entre le composant backing Bean et le composant métier ; ils forment un seul et unique composant qu'on appelle composant Seam. Une page JSF peut donc invoquer directement un composant métier déployé sous la forme d'un Session Bean. Figure 3 : Intégration JSF/EJB3 avec le Framework Seam Un composant Seam est une classe java du type POJO ou EJB 3.0 qui contient les pour identifier le composant pour le contexte applicatif. Exemple : déclaration d'un composant public class SessionUtilisateur { } Chaque composant Seam est déclaré sous un nom logique (ici sessionutilisateur) et l'appel de ce composant depuis une page JSF s'effectue de la façon suivante : <h:inputtext id="login" value="#{sessionutilisateur.utilisateur.login}" required="true"/> Avec ce principe, les développements JSF sont simplifiés, puisque il n'y a plus besoin de déclarer les backing beans dans le fichier de configuration faces-config.xml. 8

9 La spécification Web Beans JSR 299 ( est basée sur les concepts de ce modèle de composant et sera très certainement intégrée dans la spécification JEE Contextes Seam On accède à un composant Seam depuis son contexte. Chaque type de composant est déclaré par défaut dans un contexte mais il est facile d'étendre le contexte d'un composant. Pour cela, Seam met à disposition différents contextes : stateless qui est le contexte par défaut des composants EJB Stateless, sert pour les composants sans état. request (idem J2EE correspond à la requête HTTP) ou event qui est le contexte par défaut des composants du type POJO ou JavaBean, page (idem J2EE), le composant est accessible sur la durée de vie d'une page JSF, conversation qui correspond à un enchainement de pages. session (idem J2EE), le composant est accessible depuis la session HTTP, process, contexte utilisé pour la gestion des processus (par exemple JBPM) application (idem J2EE) est commun à toute l application web et dure jusqu à l arrêt du serveur d application Inversion de contrôle et injection de dépendances Pour que les composants puissent interagir entre eux, Seam propose un mécanisme d'injection des dépendances bijectif : un composant peut être injecté automatiquement dans un autre composant (équivalent au mécanisme d'injection des dépendances du Framework Spring), un composant peut également créer et projeter un autre composant dans un contexte (outjection) qui deviendra ainsi accessible par tous les autres composants. Il est également possible de forcer la création ou non des composants au moment de l'injection. Avec Seam, nous avons donc un mécanisme d'injection des dépendances complètement dynamique, ne nécessitant pas de configuration XML. L idée de l inversion de contrôle en anglais Inversion Of Control (IoC) est de ne pas gérer manuellement dans chaque composant la récupération des autres composants dont il a besoin, mais de le laisser faire au framework. Les composants vont ainsi pouvoir être développés indépendamment les uns des autres, en laissant le soin au Framework de faire le lien entre eux à l exécution. Chaque composant va signaler ses dépendances, et le Framework va les lui injecter. On indique une dépendance devant être injectée en ajoutant une à une variable d instance d un composant. 9

10 Le Framework va au-delà de l injection de dépendance, puisqu il va aussi gérer l opération inverse, via l pour (re-)publier après l exécution d une méthode une dépendance si sa référence a été modifiée par la méthode Gestion des conversations Actuellement, pour gérer l'état conversationnel dans une application web, la seule solution est de stocker les informations au niveau de la session HTTP, ce qui entraîne souvent des problèmes de réinitialisation ou de purge des informations. Avec Seam, on utilise ce qu'on appelle les conversations longues soit de manière implicite à partir de composants du type EJB3 stateful ou bien avec des JavaBeans en les déclarants dans le contexte de conversation. Une conversation Seam va donc englober plusieurs requêtes et un utilisateur pourra utiliser plusieurs conversations sachant que chaque conversation est complètement indépendante. Le démarrage d'une conversation longue s'effectue de manière explicite en positionnant par exemple une annotation au niveau d'une méthode métier. De la même façon une conversation est terminée à partir de sur une méthode ou bien dès qu'elle tombe en timeout Intégration avec JPA JPA (Java Persistence API) est l'api de persistance fournie par JEE5. Cette API se base en grande partie sur les concepts apportés par Hibernate, le Framework incontournable de mapping relationnel objet (ORM). JPA et Hibernate ont un mécanisme de chargement des données à la demande (Lazy Loading), pour éviter par exemple qu'un seul select sur une table parent récupère toutes les données des tables filles. Ce chargement des données à la demande n'est possible qu'à partir d'un contexte de persistance (ou session Hibernate) et généralement celui-ci n'est plus accessible depuis une page JSF de l'application web, ce qui peut parfois poser des problèmes pour l'affichage des données. Pour contourner ce problème, il y a deux solutions : implémenter une couche d'objets (DAO pour Data Acces Object) permettant de charger les objets de persistance avec toutes les données nécessaires pour l'affichage, utiliser le contournement OpenSessionInView qui consiste à maintenir le contexte de persistance ouvert pour chaque requête HTTP. Ces deux solutions, si elles fonctionnent, ont leurs limites. Dans le cas des DAO, on duplique le code et, avec la deuxième solution, on maintient le contexte de persistance ouvert pour toutes les requêtes HTTP et ce mécanisme ne convient pas vraiment aux applications JSF. 10

11 Avec Seam, la solution est beaucoup plus simple : le contexte de persistance sera réutilisé si la page web a besoin d'afficher des données supplémentaires. On a donc plus besoin d'implémenter de couche DAO Framework Hibernate Hibernate, comme tous les autres outils de mapping objet/relationnel, nécessite des métadonnées qui régissent la transformation des données d'une représentation vers l'autre (et vice versa). Dans Hibernate 2.x, les métadonnées de mapping sont la plupart du temps déclarées dans des fichiers XML. Maintenant, avec la spécification java EE5, les annotations sont disponibles pour arriver au même résultat avec une très grande élégance. Eclipse, par exemple, prend en charge la complétion automatique et la coloration syntaxique des annotations du JDK 5.0. Les annotations sont compilées en bytecode et lues au moment de l'exécution (dans le cas d'hibernate, au démarrage) en utilisant la réflexion, donc pas besoin de fichiers XML externes. La spécification EJB3 reconnaît l'intérêt et le succès du paradigme du mapping objet/relationnel transparent. La spécification EJB3 standardise les APIs de base et les métadonnées requises par n'importe quel mécanisme de persistance objet/relationnel. Hibernate EntityManager implémente les interfaces de programmation et les règles de cycle de vie telles que définies par la spécification de persistance EJB3. Avec Hibernate Annotations, ce wrapper implémente une solution de persistance EJB3 complète (et autonome) au-dessus du noyau mature d'hibernate. On peut utiliser soit les trois ensembles, soit les annotations sans le cycle de vie et les interfaces de programmations EJB3, ou même Hibernate tout seul, selon les besoins techniques et fonctionnels du projet. On peut à tout moment recourir aux APIs natives d'hibernate ou même, si besoin est, à celles de JDBC et au SQL. Dans ce projet, nous avons utilisé Hibernate tout seul pour le mapping objet/relationnel car, le cycle de vie est géré par le Framework Seam. Conformément à la documentation officielle de Hibernate, nous avons créé un wraper connu sous le nom de HibernateUtil dans un contexte statique pour la gestion des transactions Framework JSF, Facelets JSF (Java Server Faces) est un framework java de développement web. A l inverse des autres frameworks traditionnels MVC (Model Vue Controler) à base d actions, le framework JSF est basé sur la notion de composants comparable à celle de 11

12 SWING ou SWT, où l'état d'un composant est enregistré lors du rendu de la page, pour être ensuite restauré au retour de la requête. JSF est agnostique à la technologie de présentation. Il utilise JSP par défaut, mais peut être utilisé avec d'autres technologies Composants RichFaces Les deux jeux de composants standard de JSF s'avèrent trop limités et insuffisants pour le développement d'applications d'entreprise. Il est possible dès lors d'utiliser des jeux de composants additionnels qui offrent de nouveaux composants plus riches. Nous pouvons citer : ICEfaces, un jeu de composants open-source supportant Ajax jboss RichFaces et Ajax4JSF, un jeu de composants open-source supportant Ajax Apache Tomahawk, un jeu de composants très riche et open-source. Dans ce projet, nous avons utilisé les composants RichFaces. RichFaces est une libraire de composants riches pour les pages JSF et un framework avancé pour faciliter l integration de fonctionnalités ajax au développement des applications web. Les Composants richefaces sont prêtent à l emploi dont l intégration à une application web basée sur la plateforme Seam est fiable et riche. Sans oublier que les richfaces inclu un fort support de customisation des applications JSF. Ils tirent aussi avantage des bénéfices du framework jsf en ce qui concerne le cycle de vie la validation et les facilites de conversion ainsi que le management des ressources statiques et dynamiques. Richfaces différent des autres approches AJAX en permettant un support ajax orienté pages au lieu du traditionnel support orienté composant. Cela dit on peut définir un événement dans une page, qui invoque une requête ajax particulière et donc on peut aussi définir les zones de la page qui seront synchronisés avec l arbre des composants jsf après que cette requête particulière soit traitée par le serveur. 4. Configuration de l environnement de développement 4.1. Serveur d application Tomcat 6.0 Un serveur d'applications est un serveur sur lequel sont installées les applications utilisées par les usagers (les clients). Ces applications sont déployées sur le serveur d'applications et les clients y accèdent à distance souvent par réseau. Dans l'entreprise actuelle, l'outil informatique (appelé aussi SI pour Système d'information) a pris une place centrale et prépondérante. Il prend en charge des applications dans toutes les 12

13 étapes du processus métier, de la production à la comptabilité. Ces applications, qui étaient souvent déployées sur différents postes (clients lourds), sont aujourd'hui de plus en plus centralisées sur des serveurs d'applications, sollicités par des postes clients plus nombreux et légers (clients légers, riches, ou semi-lourds). A l'inverse ces serveurs sont des systèmes de plus en plus lourds prenant en charge des applications de l'entreprise de plus en plus diverses et nombreuses. Un serveur d'applications est donc un serveur qui centralise toutes les applications utilisées par les postes clients. Les applications sont chargées sur le serveur tandis que leurs IHM (Interfaces Hommes-Machines) sont distribuées sur les postes clients. Dans une infrastructure N-tiers régulière, on peut déployer plusieurs serveurs d'applications, que ce soit pour répartir la charge lorsque le nombre élevé de postes clients est une exigence critique, ou que ce soit simplement pour les redonder lorsque leur disponibilité est aussi une exigence critique (les dispositifs de redondance peuvent être plus ou moins sophistiqués suivant qu'ils garantissent des temps de reprise en secours plus ou moins brefs, i.e. une disponibilité de service plus ou moins continue). Le serveur d'applications agit comme tout serveur, il prend la requête du poste client, exécute les traitements à effectuer et retourne le résultat au poste client. Ce faisant, il assure la persistance des données au cours et entre plusieurs transactions d'un même poste client, ainsi que la persistance des données partagées et les arbitrages d'accès entre plusieurs postes clients concurrents. Nous avons configuré le serveur d'application Tomcat 6.0 manuellement. Pour ce faire, nous avons modifié le fichier server.xml et spécifié le contexte de notre application comme suit: <Context docbase="ter_cms_jboss_seam" path="/ter" reloadable="true" source="org.eclipse.jst.jee.server:ter_cms_jboss_seam"/> </Host> L'élément Context doit être placé avant la fermeture de l'élément Host. Les attributs les plus importants sont les suivants : «docbase» permet de spécifier un nom de l'application sur le serveur d'application «path» correspond au chemin d'accès du contexte «reloadable» permet le redéploiement ou non de l'application web sur le serveur d'application Ensuite nous avons inclus des fichiers.jar correspondant aux librairies nécessaires au fonctionnement de l'application dans le répertoire. Notamment le JDBC (java database connector) permettant de relier les objets persistants à la base de données. 13

14 Dans toutes applications web, tous les utilisateurs sont identifiés par une session. La session contient des informations sur l'utilisateur. Un exemple typique est celui du site de commerce : les produits du panier sont mémorisés pendant toute la session. Dans le but d'éviter que les sessions s'accumulent très rapidement, il est nécessaire de les détruire après un certain temps d'inactivité de l'utilisateur. Pour cela, il faut définir la valeur du session-timeout dans le fichier web.xml de Tomcat: <session-config> <session-timeout>30</session-timeout> </session-config> 4.2. Configuration Hibernate Parce qu'hibernate a été conçut pour fonctionner avec des environnements différents, Il existe beaucoup de paramètre de configuration. Nous n'allons donc pas détailler toute cette configuration mais simplement énoncé quelques une qui nous ont permis de configurer Hibernate pour l'application. Ces configurations se trouvent dans le fichier hibernate.cfg.xml. Tout d'abord, nous devons spécifier les paramètres de connexion à la base de données. Dans l'extrait du fichier hibernate.cfg.xml ci-dessous, nous avons décrit les propriétés nécessaires permettant de se connecter à notre base de données MySql en indiquant, notamment, la propriété de génération automatique de la base de données hbm2ddl.auto. En effet, ceci permet, grâce aux annotations de Java Persistance API mentionnées dans les classes Java de créer les tables dans la base de données. <property name="connection.url">jdbc:mysql://localhost/cms</property> <property name="connection.url">jdbc:mysql://localhost/cms</property> <property name="connection.username">root</property> <property name="connection.driver_class">com.mysql.jdbc.driver</property> <property name="dialect">org.hibernate.dialect.mysqldialect</property> <property name="connection.password"></property> <property name="transaction.factory_class"> org.hibernate.transaction.jdbctransactionfactory </property> <property name="hbm2ddl.auto" >update</property> <property name="connection.username">root</property> Ces classes Java doivent, cependant, être mentionnées dans ce même fichier de configuration : <!-- Mapping des entites --> <mapping class="entite.file"/> <mapping class="entite.contenu"/> <mapping class="entite.contenutext"/> <mapping class="entite.rubrique"/> <mapping class="entite.article"/> <mapping class="entite.nouvelle"/> <!-- Mapping de la classe concrête devant implémenter l'interface IUtilisateur --> <mapping class="entite.utilisateur"/> 14

15 5. Mise en œuvre et réalisation 5.1. Diagrammes des cas d utilisation Back end Figure 4 : Diagramme de cas d'utilisation Back-end Le diagramme de cas d utilisation (Figure 4) présente les acteurs intervenant dans la partie Back-End ainsi que les différents cas d utilisation. L acteur Rédacteur peut ajouter un contenu et modifier ses propres contenus. L acteur Gestionnaire peut, en plus de l acteur Rédacteur, modifier tous les contenus et les valider ou non pour les publier. 15

16 L acteur Administrateur aura accès à toutes les fonctionnalités de gestion du C.M.S. Il pourra notamment gérer les utilisateurs, gérer le contenu et gérer la configuration du site Front end Figure 5 : Diagramme de cas d'utilisation Front-end Le diagramme de cas d utilisation (Figure 5) présente les acteurs intervenant dans la partie Back-Front ainsi que les différents cas d utilisation. Un acteur Visiteur représente n importe quel utilisateur consultant le site n étant pas identifié. Il pourra consulter le contenu public ou s inscrire pour devenir membre. Ce dernier pourra consulter le contenu privé. 16

17 Implémentation du contenu Figure 6 : diagramme de classe (entités) Pour gérer le contenu du C.M.S., nous avons implémenté le design pattern Composite. La classe Rubrique est l élément composite, la classe Contenu est le composant et les classes Article et Nouvelle sont les «feuilles». De cette façon, nous avons créé une classification de type «système de gestion de fichiers» avec la Rubrique qui est composé de Contenu (Rubrique, Nouvelle, Article). En utilisant le design pattern Composite, nous simplifions l évolution de cette partie Contenu. En effet, il sera facile de rajouter tout type de contenu dans une rubrique. Pour ce faire, il suffit de spécifier la classe contenu par un nouveau type de Contenu. Par exemple, nous pourrions ajouter un Contenu de type GallerieImage qui correspondrait à un ensemble d image. 17

18 Figure 7 : Composants Seam de traitement Les composants Seam (Figure 7) permettent de traiter et manipuler des données entre la partie métier et les interfaces de l application (pages JSF). Voici les responsabilités de ces composants : Initialisation : permet d initialiser le C.M.S. en créant un utilisateur administrateur et une Rubrique racine. Authentification : permet l authentification des utilisateurs pour accéder à la partie Back-End Inscription : permet l inscription d utilisateur. SessionUtilisateur : permet de gérer la session d un utilisateur une fois connecté sur la partie Back-End en gardant les informations sur cet utilisateur. GestionUtilisateur : permet de gérer les utilisateurs du C.M.S. (ajout, modification, suppression) GestionContenu : permet de gérer le contenu du C.M.S. (ajout, modification, suppression) ainsi que les droits des utilisateurs. GestionMenu : permet de gérer les liens d accès aux pages dans la partie Back-End. GestionFrontEnd : permet de gérer le contenu dans la partie publique du site. GestionMenuFrontEnd : permet de gérer les liens d accès aux pages dans la partie Front-End. GestionNews : permet de gérer les nouvelles dans la partie publique du site. FileUploadBean : permet de gérer les logos et les fichiers (ajout, modification, suppression) pour un contenu donné. 18

19 Figure 8 : Classes Utilitaires Les Classes Utilitaires offrent différentes méthodes statiques appelées par les composants Seam. Ces classes ont les responsabilités suivantes : RubriqueConverter et UtilisateurConverter : permet de convertir respectivement un objet de type Rubrique ou Utilisateur en chaine de caractères et vice-versa. Ceci est indispensable pour récupérer un objet à partir d une liste déroulante de chaines de caractères identifiant l objet. EnumUtil : permet de récupérer l ensemble des valeurs de différentes Enumération. HibernateUtil : permet de gérer les transactions avec la base de données en récupérant la session courante. DataUtil : permet de charger des objets ou des listes d objet depuis la base de données Gestion des droits d utilisateurs Contrainte sur l'implémentation des utilisateurs D'après le cahier des charges, le C.M.S. doit pouvoir s'adapter à une application spécifique. Ceci implique que, dans le cas où cette application implémente une gestion des utilisateurs, le 19

20 C.M.S. devra s'en servir pour ne pas avoir à gérer les droits de deux façons séparées. De plus, cette adaptation devra s'effectuer le plus simplement possible avec le minimum de changement dans le code dans le but de faciliter l'intégration du C.M.S Solution adoptée La solution retenu est de créer une interface appelée IUtilisateur.java : package entite; public interface IUtilisateur { } public long getid_utilisateur(); public void setid_utilisateur(long id_utilisateur); public String getlogin(); public void setlogin(string login); public String getnom(); public void setnom(string nom); public String getprenom(); public void setprenom(string prenom); public String getmotdepasse(); public void setmotdepasse(string motdepasse); public String getconfirmation(); public void setconfirmation(string confirmation); public String get (); public void set (string ); public boolean iscompteactive(); public void setcompteactive(boolean compteactive); public String getwebsite(); public void setwebsite(string website); public boolean isadmin(); public void setadmin(boolean admin); public boolean isaccesbackend(); public void setaccesbackend(boolean accesbackend); Il suffit d'implémenter cette interface avec une nouvelle classe ou avec une classe déjà existante dans l'application spécifique. Chaque appel à une propriété d'un utilisateur dans le C.M.S. fera appel à cette interface ce qui permet une adaptation simplifiée à l'application spécifique. 20

21 modification à effectuer pour l'adaptation Malgré l'utilisation d'une interface, certains changements doivent être tout de même appliqués dans les fichiers suivants : Fichier de configuration d'hibernate - Le mapping de la classe Utilisateur est nécessaire au bon fonctionnement de l'application. Cette classe concrète doit implémenter la classe IUtilisateur soit par une classe de l'application spécifique, soit par une nouvelle classe. Le chemin d'accès à cette classe doit donc être modifié selon le cas de figure dans le fichier hibernate.cfg.xml : <!-- Mapping de la classe concrête devant implémenter l'interface IUtilisateur --> <mapping class="entite.utilisateur"/> La classe Contenu et la classe Rubrique - De la même manière que précédemment, une modification peut-être nécessaire pour faire le mapping des objets persistants Rubrique et Contenu. ) targetentity=utilisateur.class, cascade={cascadetype.persist, CascadeType.MERGE} ) targetentity=utilisateur.class, cascade={cascadetype.persist, CascadeType.MERGE} nullable=true) public IUtilisateur getauteur() { return auteur; } [...] Le composant d'initialisation - L'attribut admin doit avoir le même type que celui de la classe implémentant l'interface IUtilisateur. public class Initialisation { private Utilisateur admin; 21

22 5.3. Gestion des droits Implémentation des droits Comme nous l'avons vu précédemment, chaque contenu est classé selon une hiérarchie arborescente. Cette classification va nous permettre de gérer les droits des utilisateurs sur le contenu. Nous avons défini trois statuts d'utilisateurs ayant accès à la partie d'administration du C.M.S. (voir Figure 5). Selon leur statut, ces utilisateurs auront des droits différents. Le statut administrateur est géré très simplement avec une propriété directement liée à l'utilisateur qui indique si ce dernier est administrateur ou non (IUtilisateur.java): public boolean isadmin(); public void setadmin(boolean admin); La gestion des statuts gestionnaire et rédacteur est plus délicate. En effet, selon les spécifications du cahier des charges, un utilisateur pourra être gestionnaire d une rubrique, seulement rédacteur pour une autre rubrique, et n avoir aucun droit sur une troisième rubrique. Pour répondre à cette contrainte, la solution adoptée a été d'ajouter à chaque rubrique deux listes d'utilisateurs (Rubrique.java): private List<IUtilisateur> listredacteur = new ArrayList<IUtilisateur>(); private List<IUtilisateur> listgestionnaire = new ArrayList<IUtilisateur>(); Une première liste contient les gestionnaires de la rubrique et une seconde liste contient les rédacteurs de la rubrique. Ainsi, chaque rubrique connaîtra, par l'intermédiaire de ses listes, si un utilisateur à des droits Comment gérer les droits? L'affectation du statut administrateur s'effectue via l'interface de Modification d'un utilisateur (Figure 9). 22

23 Figure 9 : Modification d'un Utilisateur par un administrateur L'affectation des statuts Gestionnaire et Rédacteur dépendent des rubriques. Pour chaque rubrique, un utilisateur ayant les droits nécessaire (voir section suivante) peut définir les statuts via le lien 'Definir Statut' (Figure 10). Ensuite l'utilisateur aura la liste des utilisateurs inscrit et pourra ajouter, modifier ou supprimer des droits à sa convenance (Figure 11). Figure 10 : Gestion des Rubriques par un administrateur 23

24 Figure 11 : Choix des Gestionnaires et Rédacteur Qui affecte les droits aux utilisateurs? Le statut Administrateur peut seulement être modifié par un utilisateur administrateur. A l'initialisation du C.M.S., un administrateur est automatiquement créé, ce dernier pourra, par conséquent, affecter de nouveaux utilisateur avec le statut d'administrateur (Figure 9). Le statut Gestionnaire peut être modifié par un utilisateur administrateur ou par un utilisateur gestionnaire de la rubrique parent de la rubrique à modifier (voir Annexe : Classe GestionContenu, méthode droitdefinirgestionnaire()). Le statut Rédacteur peut être modifié par un utilisateur administrateur ou par un utilisateur gestionnaire de la rubrique à modifier (voir Annexe : Classe GestionContenu, méthode droitdefinirredacteur()) Conséquence des droits sur le contenu Exemple : L'utilisateur soule est affecté en tant que rédacteur de la rubrique faculté des sciences um2 (Figure 11) 24

25 après s'être authentifié, soule peut ajouter un contenu à n'importe quel niveau de la hiérarchie descendante de la rubrique faculté des sciences um2 Figure 12 : ajout d'un contenu de l'utilisateur soule soule peut modifier les contenus qu'il a créé mais n'a pas le droit de publication et de suppression Figure 13 : gestion des rubriques de l'utilisateur soule 25

26 5.4. Templates de pages web Le templating en français création de modèle de page, consiste à factoriser la structure commune d'un ensemble de pages et à l'extraire dans une nouvelle page, appelée template ou modèle. Les autres pages utilisent alors le template comme structure et y injectent leur contenu spécifique. Le templating offre plusieurs avantages : Uniformiser la structure des pages. Simplifier la mise à jour : une modification dans le template se propage automatiquement dans toutes les pages qui l'utilisent. Gain en productivité : moins de code à écrire : une page ne contient que ce qui lui est propre. Grace à l utilisation des facelets dans notre application, nous avons pu faire du templating, qui est non seulement utile pour éviter la recopie de code mais aussi pour la réutilisation des composants. Les deux tempates se trouve dans le répertoire /template. Chaque page de l application (.xhtml) est donc une composition d une page templateadmin.xhtml, qui affiche l entête de la page, le menu de navigation, le pied de page, dont on redéfinie le contenu. Dans le cas de la partie «Backend» chaque page est une composition de template-admin.xhtml qui est une composition de header-admin.xhtml en y ajoutant le menu.xhmtl et footer.xhtml. La page admin-xhtml utilise ce template et rédéfinit le contenu afin d acquérir l élément courant grâce à un composant seam qui retourne la page courante à insérer. Le squelette du template de la partie administration est le suivant : <body> <ui:insert name="header"> <ui:include src="header.xhtml"/> </ui:insert> <ui:insert name="navigation"> <ui:include src="navigation.xhtml"/> </ui:insert> <ui:insert name="content" /> <ui:insert name="footer"> <ui:include src="footer.xhtml"/> </ui:insert> </body> Les balises importantes qu il convient d expliquer sont : 26

27 <ui :include> : Permet simplement d inclure une page xhtml dans cette portion du template, cela permet généralement d inclure des entêtes et pieds de pages. <ui :insert> : Cette balise est certes la plus importante et magique, elle permet à une page cliente de redéfinir son propre contenu et de l insérer à cet endroit du template qu elle utilise. Elle a un nom unique permettant de l identifier. Nous remarquons que seule la partie <ui:insert name="content" /> sera redéfinit par la page cliente utilisant ce template, ce qui rend cette partie du template dynamique et réutilisable. Si une page veut être cliente ou veut utiliser un template, elle doit spécifier qu elle utilise le templateà l aide de la balise <ui:composition> qui prend comme paramètre le chemin vers le fichier contenant le template. Pour définir les différents blocs qui seront injectés dans le template, on utilise la balise <ui:define>. Cette balise prend comme paramètre le nom logique du bloc correspondant dans le template et contient dans son corps le contenu à injecter dans le template. Ainsi pour la partie Administration de notre application, la page cliente admin.xhtml définit la balise : <ui:composition template="template/template-admin.xhtml"> </ui:composition> De la même façon nous avons réalisé la partie publique, dont voici un aperçu : Figure 14: Front- end 27

28 5.5. Gestion des exceptions Seam nous permet d intercepter toutes les exceptions qui se produisent en dehors du contexte applicatif d un composant de deux manières qui peuvent être utilisées conjointement : Par annotation des classes d exceptions, Exemple message="erreur contenu") public class ContenuException extends RuntimeException {... } Cette exception se traduit par un message à l utilisateur et l annulation de la transaction courante avec une redirection vers la page error.xhtml. Par le fichier de configuration pages.xml : Cette méthode a l avantage de pouvoir intercepter toute sorte d exceptions. Ces deux possibilités sont complémentaires car, on ne peut annoter toutes les exceptions qu on veut, c est pourquoi Seam autorise l utilisation du fichier XML afin d intercepter ces dernières. Pour que Seam soit capable d intercepter des exceptions, il faut tout d abord déclaré le master servlet dans le fichier web.xml de la manière suivante : <filter> <filter-name>seam Filter</filter-name> <filter-class>org.jboss.seam.servlet.seamfilter</filter-class> </filter> <filter-mapping> <filter-name>seam Filter</filter-name> <url-pattern>*.seam</url-pattern> </filter-mapping> Dans ce projet, nous avons choisi la deuxième méthode celle à l aide du fichier XML car, elle permet d intercepter toute sorte d exception se produisant en dehors du contexte applicatif d un composant Seam. Par exemple pour intercepter une exception et afficher un message compréhensible à l utilisateur quand sa session a expiré : <exception class="javax.faces.application.viewexpiredexception"> <redirect view-id="/error.xhtml"> <message>votre session a expiré, merci de la renouveler!</message> </redirect> </exception> Dès qu une exception ViewExpiredException se produit, l utilisateur est automatiquement redirigé vers la page d erreur error.xhtml avec un message clair lui montrant qu il doit renouveler sa session. 28

29 6. Conclusion 6.1. Apports personnels Ce projet nous permis de mettre en pratique nos connaissances dans les domaines suivants : Gestion de projet : planification et répartition des tâches, le travail en équipe Développement autour des technologies de pointes : Hibernate,Seam, JSF et Facelets Ce dernier point nous ont permis d acquérir de nouvelles compétences et de découvrir la puissance, la rapidité de développement, les composants riches mis à disposition par la bibliothèque RichFaces, l injection de dépendance dans le framework Seam ainsi que l élégance du framework Seam d orchestration entre les composants métiers et les vues. Il a mis en jeu des compétences de synthèse et d analyse nécessaire pour, à partir d une situation complexe, dégager le travail à faire et la méthodologie à adapter. L enjeu d envergure de produire les bases d une application logicielle qui sera utilisé par tous les collaborateurs d IOCEAN a rendu ce projet très motivant Apports pour IOCEAN L outil ainsi réalisé répondant parfaitement au cahier des charges permettra à IOCEAN de disposer d une application de gestion de contenu entièrement développée sur des technologies Java/JEE à savoir : Hibernate, Seam, JSF et Facelets. L outil étant facilement adaptable, il pourra être intégré à une application spécifique des clients d IOCEAN que ce soit un intranet informatif ou un portail web Perspectives Bien que l outil soit opérationnel et par manque de temps, certaines améliorations peuvent y être apportées : La possibilité de joindre des fichiers aux articles ou rubriques La confirmation de suppression d un contenu Le choix de supprimer une rubrique parente avec sa descendante ou non Intégration d une galerie d images comme contenu Transformation de quelques composants créés en des composants Facelets par la création des taglib personnalisées. Intégration d une stratégie de gestion des templates de pages afin de pouvoir modifier la charte graphique de la partie publique ou privée de manière automatisée. 29

30 7. Annexes Dans cette partie, nous allons donner quelques copie d écrans de quelques pages de notre application. Ainsi tout accès à la partie Back-end est réservé aux membres ayant un accès autorisé par un des administrateurs par une validation. Toute inscription est soumise à validation des administrateurs. Les champs sont validés grâce à Hibernate Validator et AJAX Support de RichFaces. La page d inscription d un nouvel utilisateur est la suivante Figure 15: inscription 30

31 Figure 16: Authentification pour accès à la partie administration Une fois authentifié, on arrive à la page d accueil de la partie administration du CMS, qui se présente comme suit : Figure 17 : Accueil Back-end Sur cette page, nous avons la possibilité d ajouter des articles, des rubriques, gérer les rubriques et articles dont on a le droit de gestionnaire, modifier ceux dont on a le droit de rédacteur. Seuls les administrateurs ont accès à toutes les fonctionnalités du CMS. 31

32 Pour des raisons d ergonomie et de lisibilité, sur le reste des screeshots nous ne montrerons que le bloc du milieu qui change selon les pages. La page d ajout d une rubrique permet de choisir une image servant de logo pour la rubrique, un titre, la rubrique parente à laquelle elle sera rattachée du point de vue structure de données, un lien web. Figure 18 : Ajout d'une rubrique Une fois la rubrique créée nous arrivons à la page de gestion des rubriques, présentant la liste toutes les rubriques dans une datatable : Figure 19 : page de gestion des rubriques De cette page, nous pouvons : modifier l état d une rubrique, définir les gestionnaires et/ou rédacteurs d une rubrique donnée si on est administrateur, définir les rédacteurs d une rubrique pour laquelle on est gestionnaire. 32

33 Supprimer une rubrique si on est administrateur. Pour plus de détail pour la gestion des droits sur les rubriques, articles, veuillez vous référez à la partie concernée. Figure 20 : Définition des gestionnaires et/ou rédacteurs pour la rubrique sélectionnée. La page d ajout d un article comprend quand à elle : Un lien permettant de joindre une image qui servira de logo pour l article Des zones de saie pour le titre, sous titre, etc. Une grande zone de saisie permettant de saisir le corps de l article, c est en fait l élément le plus important. Il s agit du composant RichEditor de la bibliothèque RichFaces. Ce composant permet d insérer des images dans le texte, des mises en forme, l insertion de sources.doc etc. 33

34 Figure 21 : Ajout d'un article Gestion des utilisateurs Figure 22 : Gestion des utilisateurs d erreur de l application : Toutes exceptions qui se produisent dans l application conduit à une redirection de l utilisateur vers la page d erreur avec l affichage d un message compréhensible par ce dernier. Voici typiquement le genre de message qu on peut avoir, ici la session de l utilisateur a expiré et il essaye d accéder à des ressources protégées. 34

35 Figure 23 : d'erreur On n a pas pu présenter toutes les pages et fonctionnalités de notre application dans ce rapport, pour découvrir toutes les fonctionnalités de notre application, veuillez suivre la démonstration. La partie publique présente les rubriques, les articles publiés dans des composants spécifiques. La page d accueil de la partie publique du CMS : Figure 24 : Accueil Front-end 35

36 Liste des rubriques publiées : Figure 25 : Rubriques publiées dans le front-end Le composant Dernières publications contient les cinq dernières publications. Le composant Archives contient les anciennes publications : 36

37 Figure 26: Dernières publications Figure 27 : Archives 37

38 Liste des articles publiés : Figure 28 : liste articles publiés Consultation d un article sélectionné : Figure 29: Consultation article 38

39 8. Bibliographie Lien d'une étude de cas sur Facelets Lien tutorial sur Facelets Lien du groupe Présentation des requêtes Hibernate SQL Seam documentation officielle : Hibernate documentation officielle : JSF La bibliothèque composants "JSF Core" (préfixe f:) : La bibliothèque composants "JSF HTML" (préfixe h:) : RichFaces: la démo / documentation des composants : Facelets la documentation officielle n'est pas très intéressante : deux articles beaucoup mieux, qui constituent un tutoriel très intéressant : documentation très intéressante sur le framework RichFaces o Lien du wiki de l application : 39