Ce guide d’implémentation décrit l’implémentation choisie pour la partie présentation de l’application web du système ePims.

Figure 1 Architecture globale de l’application

Comme indiqué sur ce schéma ( se référer aux spécifications pour plus d’informations) :

• Les JSP/JSF sont utilisés pour la partie présentation.
• Au niveau de la logique applicative on utilise le framework Spring qui est un conteneur léger et qui permet, d’une part, d’isoler les différentes technologies utilisées et ainsi de faciliter la substitution d’une implémentation par une autre. Et, d’autre part, Spring prend en charge la partie transactionnelle de O/RM.
• Hibernate a été choisi pour la partie O/R Mapping. Ce framework a, entre autres, l’avantage de s’interconnecter facilement avec Spring.

Du côté de la couche présentation, on trouve :

• Les backing beans, définis dans le package view, sont utilisés par JSF pour présenter les données. Ces beans correspondent, en principe, aux objets du package BO, ils définissent des accesseurs aux différentes propriétés ainsi que des méthodes de type action. De plus, ces objets doivent avoir accès à l’objet ServiceLocator afin de manipuler les données du modèle.

Le projet eP-Web est développé sous MyEclipse, voir le guide de développement pour plus de détails sur l’environnement de développement nécessaire.

Il existe deux fichiers de taches Ant : build.xml et build-ivy.xml. Pour tout ce qui concerne ivy (resolve pour récupérer les librairies nécessaire …) il faut utiliser build-ivy.xml.

Sinon, dans build.xml, il existe des cibles spécifique à la distribution en mode production et des cibles spécifiques au développement. On retrouve donc, entre autre, les cibles

• configure.dist : Configure l'application pour le déploiement en mode production (copie des fichiers de configutations, mise en place de librairies…).
• configure.dev : Même configuration que précédement mais utilise les fichiers de configuration pour exécuter le mode développement.
• configure.test : Même configuration que précédement mais pour le mode test (utilisation du serveur de test : image du serveur de prod)
• dist : appel configure.dist et crée le .war pour la prod.
• dist.test : appel de configure.test et crée le .war pour le déploiement sur le serveur de test..

Attention : Les différentes cibles définies ici sont dédiées à un environnement utilisant un IDE. En effet, il n'y a pas la compilation ou de définition de classpath !

Le fichier eP-Core.properties (./resources/main) contient les propriétés utilisées par eP-Core et qui peuvent nécessiter d’être redéfinies. L’utilisation d’un fichier permet de modifier ces propriétés sans avoir à recompiler l’application. D'autre part, chaque projet qui utilise eP-Core peut spécifier un fichier de propriétés user dans lequel il aura redéfini tout ou partie des propriétés. Lorsque le programme utilisateur de eP-Core a redéfini des propriétés il doit le spécifier à eP-Core. Pour cela il doit :

• Définir une propriété système, ResourceManager.USER_RESOURCE_PROPERTY, qui a pour valeur le nom du fichier properties où sont redéfinis les propriétés
• Demander au ResourceManager de lire ce fichier : ResourceManager.getInstance().loadUserRB() ;

  UNDEF_DIR_NAME=_UNCLASS_   1.
  PIMS_ROOT=  /local/path/to/pims_root/   2.
  PIMS_REPOSITORY_1=  a   3.
  PIMS_REPOSITORY_2=  b   4.
  PIMS_REPOSITORY_3=  c   5.
  PIMS_SHARE=  b/share   6.
  PIMS_ARCHIVE=  transfert/archive   7.
  PIMS_SYSTEM = adm   8.
  PIMS_ARCHIVE_FILE =  path/relative/to/pims_system/studyArchived.txt   9.

1. Nom des répertoires, sur le SAN, contenant les projets/études n’appartenant pas à un programme/projet.
2. Répertoire racine où les données de Pims peuvent être trouvées
3. Répertoires, depuis PIMS_ROOT, dans lesquels les données relatives aux études sont stockées.
4. Répertoires, depuis PIMS_ROOT, dans lesquels les données relatives aux études sont stockées.
5. Répertoires, depuis PIMS_ROOT, dans lesquels les données relatives aux études sont stockées.
6. Répertoire contenant les données dites partagées, n’appartenant pas spécifiquement à une étude. On retrouve ici, par exemple, les acquisitions de contrôles réalisées sur les instruments.
7. Répertoire, depuis PIMS_ROOT, dans lequel sont transférés les données qui sont à archiver (à copier sur bandes)
8. Répertoire, depuis PIMS_ROOT, dans lequel les données “administratives” et systèmes sont sauvegardées (logs files…)
9. Fichier copié dans les répertoires des études lorsque celles-ci sont archivées afin d’en avertir l’utilisateur. Ce fichier est donné avec le projet. Il doit contenir un tag « #DATE#. » qui sera remplacé par la date effective à laquelle l’étude a été archivée. Le chemin spécifié est relatif à celui spécifié pour PIMS_SYSTEM

L'accès aux services fournis par eP-Core se fait via la classe ServiceLocator. Cette classe contient, pour chaque service, une méthode getter (sous la forme getXXX(): XXX nom du service ) retournant une instance du service en question. Exemple de méthodes : getStudyService() retourne une instance d'un objet donnant accès à tous les services concernant les études.

Plusieurs librairies sont utilisées par eP-Web. Certaines sont des librairies développées au sein du laboratoire, d’autres sont des librairies open source. Les librairies utilisées peuvent réclamer la présence de librairies tierces et deux librairies peuvent éventuellement nécessiter des versions différentes d’une même librairie.

Afin de gérer les différentes librairies utilisées, ainsi que les différentes versions de celles-ci, le gestionnaire de dépendance de librairies Java IVY est utilisé.

Les librairies sous le serveur JSP Tomcat sont organisées dans plusieurs répertoires. Sous chacun d’eux on retrouve un sous répertoire lib contenant les .jar et un sous répertoire classes contenant les classes compilées Java.

L’organisation et l’accessibilité des libraires est la suivante :

• Les ressources sous TOMCAT/server ne sont visibles que par TOMCAT.
• Les ressources sous TOMCAT/common sont accessibles à TOMCAT et aux différentes applications WEB.
• Les ressources sous TOMCAT/shared sont accessibles à toutes les applications web mais pas au serveur TOMCAT.
• Les ressources spécifiques à un projet sont sous le répertoire WEB-INF du projet en question. (WEB-INF/lib pour les jars et WEB-INF/classes pour les classes)

Par conséquent, lors de la recherche d’une ressource, l’ordre est le suivant :

• /WEB-INF/classes de l’application web
• /WEB-INF/lib/*.jar de l’application web
• TOMCAT/common/classes
• TOMCAT /common/endorsed/*.jar
• TOMCAT /common/lib/*.jar
• TOMCAT /shared/classes
• TOMCAT /shared/lib/*.jar

Le projet se compose en trois grandes parties : la parties Interfaces , la partie Logique applicative, et la partie contrôle. Voici le contenu de chacune d'elles:

Cette partie concerne toutes les pages JSP qui donnent accès aux différentes fonctions. Il existe deux types de pages: pages accessibles par tous les utilisateurs , et pages accessibles uniquement par les utilisateurs ayant le statut administrateur. Ces dernières sont différenciées des pages accessibles pas tous les utilisateurs par le fait qu'elles soient dans un répertoire à part (epims/pat), de telle sort que lorsqu'un utilisateur non administrateur se connecte, les pages “admin”, c'est à dire celles qui se trouvent dans le répertoire pat, ne sont pas accéssibles.

Cette partie est constituée en trois types de classes :

1. les Backing Beans,définis dans le package view, sont utilisés par JSF pour présenter les données;
2. les classes utiles, définis dans le package view, qui sont les suivantes : les classes Convertor, les Component, les classes d'export, les Validator pour la vérification des données avant de les insérer dans la base de données;
3. les fichiers de modélisation pour les rapports d'export de JasperReport , définis dans le package report,

Cette partie concerne tous les fichiers de configuration qui permettent : la configuration des Backing Bean (faces-managed-bean.xml), des navigations des pages JSP (faces-navigation.xml), configurations Spring (springAppContext.xml, springDataSource.xml) ainsi que des components utilisés dans l'application.

Nous allons lister ici quelques règles de développement que nous utilisons (elles ne sont peut etre pas optimales !) afin, d'une part d'aider à la lecture du code et d'autre part de permettre une certaine homogénisation du code développé par plusieurs personnnes….

Dans le code JAVA

• Convention Java classique : camelCase pour les noms de classes/variables…
• L'accès a d'autres beans via spring ce fait en utilisant les noms des beans définis dans BeanNames
• ParameterNames : définition des noms des paramètres qui transitent entre les pages JSF et les classes JAVA. Voir paragraphe suivant.
• PimsResources : défintion des messages utilisés dans le code
• ValuesResources : definition de constante utilisé dans le code (non partagé avec les pages JSF comme ParameterNames).
• Certaines méthodes des managed bean sont des actions des pages JSF et doivent donc retourner des String utilisées pour la navigation. Toutes ces retours sont déclarés en en-tête des bean comme constante NAV_XXXX
• GenericBean : deux managed beans generique EntityGenericBean et SpectrometerGenericBean définissent des propriétés …. générique : la liste de tous les acteurs, la liste des valeurs autorisées pour xxx, une getter methode pour chaque valeur de xxx
  • exemple :
    • getResponsibles : Liste des acteurs, pouvant être utiliséà plusieurs endroits
    • getSampleNamePatterns() : Liste des patterns autorisés pour les sampleName : Pas utilisé à bcp d'endroit mais propriétés constantes….
    • getAcquisitionProcessType : permet de faire des tests dans les pages…

Dans les pages JSF

• les noms des id sont composés avec des _ : <h:form id=“sample_reception_form”…
• Les subview pouvant être utilisés dans plusieurs pages sont sous ePims/subviews

Les backing beans sont utilisés pour la partie présentation. Ce sont eux qui contiennent les informations à l’afficher et les actions déclenchées par l’utilisateur. Il est parfois nécessaire de passer un paramètre de la page JSP au backing bean, pour cela on utilise la requête HTTP. Afin d’éviter les erreurs dans la dénomination des propriétés, on utilise une classe contenant la déclaration des noms des propriétés utilisées par les différents beans/pages. Il est également nécessaire de spécifier pour chacun de ces noms, une méthode get, utilisée dans les pages JSP. Par exemple:

 Class Names {
    public static final String PROGRAM_ID = « program_id » ;
    public String get ProgramId(){
       return PROGRAM_ID;
    }
 } 

Dans les beans, l’accès à la valeur se fait

1. soit en utilisant la variable :

   actionMethod(){
    FacesUtil.getRequestParameter(ParameterNames.PROGRAM_ID) ;
    …
   }

2. soit en spécifiant le lien entre le paramètre et une propriété du bean au niveau du fichier de configuration de JSF faces-managed-bean.xml :

     <managed-property>
          <property-name>id</property-name>
          <value>#{param.program_id}</value>
    </managed-property>

Dans les JSP:

  <f:param id=”progId” name=”#{ParamConstant.programId}” value=”2”/> 

Il est bien entendu nécessaire d’avoir spécifié le bean ParamConstant de type ParameterNames dans le fichier faces-managed-bean.xml.

Rien de spécifique à faire, mais pour info:

Aucune configuration supplémentaire à celle défini dans ePCore n'est nécessaire. Par conséquent, une fichier “vide” de configuration de Spring est créé dans ./WebRoot/WEB-INF/ et l'on définit un ApplicationContext spring dans web.xml ayant l'ApplicationContext d'eP-Core comme context parent.:

 <context-param>
    <param-name>locatorFactorySelector</param-name>
    <param-value>classpath*:springContext.xml</param-value>         
 </context-param>
  
 <context-param>
   <param-name>parentContextKey</param-name>
   <param-value>epCore.context</param-value>         
 </context-param>
<listener>
   <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
 </listener>

Tous les objets qui doivent faire appel aux services de eP-Core doivent donc récupérer l'ApplicationContext afin d’instancier le ServiceLocator. Les super-classes BaseBean et BaseConvertor, dont héritent tous les backing beans et convertor, instancient un ServiceLocator :

 ServletContext context = FacesUtils.getServletContext();
 serviceLocator_ = new  ServiceLocator(WebApplicationContextUtils.getRequiredWebApplicationContext(context)); 

Tout comme des fichiers de configuration sont nécessaires pour Spring, il existe des fichiers de configuration propre à JSF dans ./WebRoot/WEB-INF :

• faces-config.xml : contient la définition des Convertor/Validator utilisés, et des définitions spécifiques à JSF.
• faces-navigation.xml : contient les règles de navigations utilisées. Dans JSF la navigation depuis un lien ou un backing bean se fait par des mots clés qui, au niveau du fichier, correspondent à de nouvelles pages jsf.
• faces-managed-beans.xml : définition des backing beans utilisés par JSF.

Une description sommaire est donnée ici, pour plus d’information se référer à la documentation de JSF.

Foward : Transfert la requête à la page spécifiée. La requête sera visible de la page destination éventuellement augmentée de nouveaux paramètres spécifiés dans le tag forward. Redirect : C’est la réponse au client qui indique la nouvelle URL (comme http redirect), le client réclame donc la nouvelle URL, sans info de la requête précédente.

Plus précisément :

« When a Servlet or a JSP resource chooses to redirect the client using response.sendRedirect(url), the request object does not reach the second resource directly since the underlying implementation is an HTTP redirect. The server sends an HTTP 302 messages back to the client telling it that the resource has been moved to another url and that the client should access it there.

In forward mechanism, the request object is forwarded to the second resource, thus maintaining any object binding to the request and its state, without a round trip to the client on the network. »

• <jsp:forward page=“web/welcome.jsp” />

    Tells the servlet runner to start executing a different servlet. Something like a "go to" done in the server.
    Browser                         Server
    
    Request page A
                                      Execute page A code
                                      Forward to page B
                                      Execute page B code
                                      Return page B response

• response.sendRedirect(“web/welcome.jsp”);

   Return to the client browser a special tag, telling the browser to immediatly load the page described as a parameter.
   Browser                         Server
    
   Request page A
                                      Execute page A code
                                      Return redirect command
   Receive redirect
   Request page B
                                      Execute page B code
                                      Return page B response

Remarque : Si on utilise <jsp:forward …> pour accéder à une page d’une zone protégée par mot de passe, aucun mot de passe n’est demandé !!!!!!!!! Dans ce cas, il est préférable d’utiliser redirect.

• Dans WebRoot/index.jsp : modification du nom du laboratoire directement dans le fichier
• Dans le fichier src/cea/edyp/epims/view/util/messages.properties modifier le paramètre “accueil_quid_pims_labo”

• Dans le fichier src/cea/edyp/epims/view/util/messages.properties modifier le paramètre “login_pb_mail”

La page JSF permettant l’archivage n’est accessible qu’aux administrateurs. Cette page est couplée à un backing bean, ArchiveBean, permettant d’accéder aux informations utiles et de lancer les actions d'archivage.

Les informations sont :

• La liste des études archivables et pour chacune d’entre elles la taille des données associées.
• La liste des groupes de contrôles ‘archivable’ – en l’occurrence tous les groupes non encore archivés. De même, la taille de ces groupes doit être connue.
• L’état d’avancement (en cours, terminé) et le statut (OK, ERROR) des archivages.

ATTENTION : Dans l’implémentation choisie, il n’existe pas à proprement parlé d’entité représentant un groupe de contrôles. Par conséquent, il n’est pas possible de savoir si un groupe (du point de vue eP-Web) est archivé ou non.

Solution : Les différents groupes étant organisés par date, si un groupe datant de x mois est vide on peut supposer qu’il a été archivé. On peut également, se contenter de dire que l’on ne liste que les groupes non vides, sans se préoccuper de savoir si il a été archivé ou non.

A partir de ces listes, l’administrateur sélectionne certains des éléments (études et/ou groupes de contrôles) et demande à les archiver. Il est également possible depuis cette page de connaître l’état d’avancement de l’archivage. En effet, lorsque l’administrateur demande l’archivage, celui-ci est lancé mais l’application n’attend pas la fin de l’opération pour rendre la main à l’utilisateur.

Les parties Historique et Archivage sont organisées en onglets, ainsi l’utilisateur peut se concentrer sur la partie qui l’intéresse.

Depuis l’onglet Archivage, l’administrateur sélectionne les données à archiver et lance l'archivage.

Figure 2 Onglet Archivage

L’onglet Historique contient d’une part la liste des archivages en cours et, d’autre part, la liste de tous les archivages déjà réalisés depuis le lancement du serveur. Le statut des archivages est également indiqué.

Figure3 Onglet Historique

C’est le même backing bean qui est utilisé pour l’accès aux informations concernant la liste des données à archiver et pour accéder aux informations concernant l’état des opérations d’archivage.

Le backing bean gère donc, d’une part, les deux types de données, ArchivableAcquisition et ArchivableStudy, qui représentent respectivement les groupes de contrôles archivables et les études archivables et, d’autre part, les objets ArchiveOperation qui représentent les opération d’archivages.

Pour les objets ArchivableAcquisition et ArchivableStudy, un état selected est défini et il est possible de connaître la taille des données associées.

ArchivableStudy se contente d’encapsuler une Study. Ainsi, lors de l’archivage proprement dit, il suffira de déterminer l’ensemble des études sélectionnées et de faire appel aux services adéquats définis dans PitBuL.

ArchivableAcquisition représente un ensemble de toutes les acquisitions de même type ayant été réalisés le même mois sur le même instrument. Afin de ne pas parcourir toutes les acquisitions et de rechercher celles n’étant pas encore archivées puis de les regrouper, chaque instance de ArchivableAcquisition est créé en fonction des acquisitions trouvées sur le SAN. Ainsi un objet ArchivableAcquisition représente un répertoire contenant un ensemble d’acquisitions. Néanmoins, lors de la recherche de ces répertoires, on connaît les caractéristique du groupe correspondant (type, date, instrument). Ces informations peuvent être sauvegardées au niveau de ArchivableAcquisition et lors de l’archivage, il sera plus facile de déterminer quels acquisitions sont à archiver.

Les objets ArchiveOperation qui représente une opération d’archivage, sont définis par un identifiant, un statut et éventuellement une date de fin. Le statut peut être soit en cour, si l’opération d’archivage est toujours en cours, soit OK, si l’opération d’archivage s’est correctement terminé, soit invalide, si l’opération d’archivage s’est terminé sur une erreur. Le dernier état est en réalité plus complet, puisque l’objet ArchiveOperation retourne invalide seulement si il n’a pas pu déterminer la raison de l’erreur, sinon il retourne un message décrivant l’erreur qui est survenue.

La page JSF permettant d’accéder aux états de sortie est accessible à tous les utilisateurs sauf un des exports proposés (Volumétrie par Personne) n'est accéssible que pour les administrateurs. Cette page est couplée à deux backing bean, ExportTextualBean et ExportGraphicalBean, permettant de lancer les actions afin d’accéder aux différentes volumétries.

Chacun des liens de la page donne accès à d’autres pages JSF correspondant chacune au type de volumétrie choisi. Cette navigation est spécifiée dans le fichier de configuration faces_navigation.xml.

a page JSF donnant accès à cette volumétrie, state_context_volumetry.jsp, est aussi couplée au backing bean ExportTextualBean permettant d’accéder aux informations utiles et de lancer l’export.

Informations utiles :

• Données à considérer : Programmes / projets / études ou Programmes / projets
• Liste des formats du fichier d’export proposés: XLS, HTML, PDF
• Date de début et fin de la période de temps sur laquelle faire l'export.

A partir de cette page, l’utilisateur sélectionne le type d’export ainsi que le format du fichier qu’il voudrait obtenir, et de spécifier, si il le souhaite, la période de temps (en donnant la date de début et de fin) durant laquelle les données l’intéressent.

Les pages JSF donnant accès à ces deux types de volumétrie sont state_graphical_intr_volumetry.jsp et state_graphical_nature_volumetry.jsp. Ces pages sont respectivements couplées aux backing beans ExportGraphicalInstrumentBean et ExportGraphicalNatureBean. Ces deux beans dérivent de ExportGraphicalBean

A partir de ces pages, l’utilisateur peut, selon le type de volumétrie, :

- sélectionner le/les instruments sur lesquels il souhaite des volumétries ;

- sélectionner la/les natures d’acquisition sur lesquelles il souhaite des volumétries

- sélectionner l’option globale qui lui permet d’avoir la volumétrie total sur les acquisitions réalisées : sur tous les instruments / pour toutes les natures d’acquisition.

L’utilisateur spécifie, s'il le souhaite, la période de temps (en donnant la date de début et de fin) durant laquelle les données l’intéressent.

Ce lien n'est visible qu'aux administraeurs. La page JSP donnant accès à cette volumétrie, state_actor_volumetry.jsp, est couplée au backing bean ExportTextualBean qui lui permet d’afficher la liste des formats d’export proposés : XLS, HTML, PDF ainsi que d’effectuer l’export.

A partir de cette page, l’utilisateur sélectionne le format du fichier qu’il souhaite obtenir, et spécifie, s'il le souhaite, la période de temps (en donnant la date de début et de fin) durant laquelle les données l’intéressent.

ExportTextualBean, ExportGraphicalBean (et les deux classes dérivées):

Ces backing beans possèdent une méthode export() qui leur permet, selon le type de volumétrie sélectionné, d’effectuer l’export correspondant en appelant les méthodes de la classe VolumetryTextFileExport, selon les étapes suivantes :

• Identification du type de volumétrie sélectionné (volumétrie programme : complet/résumé, volumétrie par instrument, volumétrie par nature d’acquisition, volumétrie personne) dans les méthodes de la classe VolumetryTextFileExport, choisir ainsi le fichier JasperReport à utilisé et les parametres nécessaires à ce fichier;

• Identification du type de fichier sélectionné (xls, html, pdf) dans les méthodes de la classe VolumetryTextFileExport, et choisir la mise en forme adéquate du fichier JasperReport ;

Ces backing beans possèdent également des méthodes qui renvoient à la page JSP (state_context_volumetry.jsp) la liste de certaines informations telles que : le type de volumétries disponibles, les formats de fichiers proposés, les spectromètres disponibles, les natures d’analyses prises en charge par le laboratoire, … et retournent aussi les messages d'erreurs adéquats lorsqu'une exception est levée.

Les exports sur les Programmes/Projets/Etudes ainsi que sur les Personnes, étant des export textuels, des accès direct à la base de données sont effectués à partir des fichiers JasperReport pour les volumétries en spécifiant la requête dans la propriété <query> du fichier.

Par contre, les exports sur les Acquisitions, des classes JAVA se chargent d’effectuer les tâches suivantes :

• AcquisitionVolumetry : permet de récupérer toutes les volumétries concernant les acquisitions : volumétries par nature d’acquisition, volumétries par spectromètre, volumétrie globale du laboratoire, ….
• PieInstrumentAcquisitionVolumetry : cette classe se charge de la création d’un objet JFreeChart contenant un objet chart pour la représentation graphique. Cet objet sera transmis au fichier JasperReport correspondant à la volumétrie en question au moment du chargement des données et par l’intermédiaire de la classe JFreeChartScriptlet en indiquant dans la propriété « Scriptlet Class» du fichier JasperReport le nom de cette classe.

Le package JasperReport est une solution de reporting Open Source pour générer du contenu dynamique et pour créer des documents par page et prêts à être imprimeés facilement et de façon flexible. La bibliothèque JasperReport est capable de fournir du contenu riche à l'écran ou dans des fichiers PDF, HTML, XLS, CSV et XML.

JasperReport est entièrement écrit en JAVA, et peut être intégré dans toute application J2EE pour générer dynamiquement des informations de manière simple et flexible. Sous JasperReport, un document est défini par un fichier xml, appelé fichier de design, ayant l’extension jrxml. Le fichier design est ensuite compilé ( JasperFillManager.fillReport() ) en un fichier binaire .jasper qui sera peuplé de deux manières possibles

• soit par des données passées en paramètres par l’application appelante au cours de son exécution ;
• soit par des données récoltées d’une base de données dont une connexion peut être passée en paramètre par l’application appelant ou alors définie par JasperReport.

Figure 4 Classes impliquées dans les états de sortie

Figure 5 Séquence lors de l'export de la volumétrie par nature

A divers endroits de l’application Web, des listes (ou arbre) d’éléments sont affichées :

• Liste de Programmes – avec leurs projets et leurs études – (page organisation)
• Liste de Projets orphelins – avec leurs études - (page organisation)
• Liste d’Etudes orphelines (page organisation)
• Liste de Projets et/ou Etudes répondant à certains critères (résultat de recherche)
• Liste des Projets (resp. Etudes) d’un Programme (resp. Projet) donné (description d’un Programme – resp. Projet -)
• Liste d’Acquisitions répondant à certains critères (résultat de recherche)
• Liste d’Echantillons/Acquisitions/Echantillons en attente d'acquisition d’une Etude donnée.
• Liste des Programmes/Projets/Etudes appartenant à l'utilisateur.
• Liste d'Echantillons en attente d'acquisition appartenant à l'utilisateur.

L’objectif est, d’une part, d’homogénéiser l’IHM et, d’autre part, de faciliter les évolutions. En effet, tout ajout d’une fonction au niveau d’une liste sera visible aux différents endroits ou elle sera utilisé. Pour cela, le choix de l’utilisation d’un composant JSF pour l’affichage des listes a été choisi.

Il reste néanmoins à déterminer quel(s) composant(s) (composant existant ou personnalisé) et le niveau de configuration que l’on souhaite autoriser.

La particularité de ces listes est qu’elles sont des arbres ! En effet, pour chaque programme (resp. projet) on veut pouvoir avoir la liste des projets (resp. études) qui leurs sont rattachés. Par contre, ce n'est pas le cas pour les listes des études , exemple liste des études orphelines,car ceux sont de vraies listes ! En effet, les études n’ont pas d’élément qui leurs sont rattachés.

Dans le cadre de la description de l’organisation, seuls le nom du contexte et une icône sont affichés. Le statut (ouvert, clos, archivé) du contexte doit également être indiqué, par une icône par exemple. Le nom est un lien vers une page de description complète du contexte et l’icône permet l’accès à une page de description sommaires.

Enfin, lorsque l’on fait une recherche dans l’activité du laboratoire, le resultat répondant aux critères de recherche est donné sous forme de tableau pour chaque type d'entité (Programme, Projet, Etude)

Si l’on souhaite faire un composant JSF qui puisse être utilisé dans les différents cas listé ici, voire de nouveaux cas de figure non encore rencontrés, il est nécessaire d’autoriser la configuration de divers paramètres. Néanmoins, si l’on rend trop configurable le composant, plus rien n’assure l’homogénéité de l’IHM. Un compromis pourrait être de permettre :

• de paramétrer si l’on souhaite ou non voir les fils des entités.
• de spécifier le type d’affichage souhaité parmi 2 ou 3 : compact ou complet.
• de cacher/voir les entités en cours/clos

Le mode compact affiche : * le nom * la nomenclature * l’icône d’accès a la description sommaire

Le mode complet affiche le tableau de la page de description.

Dans la page de description des études, la liste des échantillons, celle des échantillons en attente d'acquisition, ainsi que celle des acquisitions sont accessibles sous forme de vues.

Liste des Echantillons : cette page , subView_study_samples.jsp, couplée au Backing Bean StudyBean offre la possibilité de modifier l'état d'un échantillon en cliquant sur la figure représentant une led, ou alors en sélectionnant les échantillons auquels on désire changer l'état et leur attribuer un nouvel état.

Dans le cas où le changement de statut se fait sur un échantillon et que ce changement concerne le passage du statut “Disponible” à “En attente d'acquisition” une pop-up s'ouvre permettant la saisie des paramètres nécessaires à la planification de l'échantillon en question:

Lorsqu'il s'agit d'un ensemble d'échantillons, une pop-up s'ouvre lorsqu'on click sur l'icône et présente selon l'état souhaité les informations nécessaires à la planification des échantillons.

Liste des Echantillons en attente d'acquisition : cette page , subview_tobeanalysed_stdSamples.jsp, couplée au Backing Bean StudyBean permet de changer certaines données en les introduisant dans les champs qui leurs sont dédiés ou le faire pour un ensemble qu'on aurait sélectioné.

Liste des Acquisitions

Une recherche d’acquisitions répondant à certains critères donne une liste (un tableau) en résultat. Cette liste doit contenir des informations autres que celles données dans la page de description. En effet, il faut préciser l’étude d’appartenance (pour les acquisitions recherche) et la nature de l’acquisition, la recherche étant faite éventuellement sur tous les types d’acquisitions.

Dans ce paragraphe, nous allons decrire la réalistion de quelques fonctions en décrivant l'organisation des pages JSF et les Backing Bean utilisés.

ATTENTION: Ce chapitre n'est pas correcte !! Il correspond déjà à la version 4.0 !!!

Remarque : dans le texte process = protocol_application du modèle… EntityGenericBeanBean (Request): Bean utilisé pour récuperer des infos generic : liste de tous les contacts, tous les acteurs…

SpectroGenericBean (Request) : Bean utilisé pour récupérer les infos générique autour de la spectro :liste de tous les types d'instruments,…

SamplesReceptionBean(Session): Bean utilisé pour la création des samples. Gestion de la liste des samples en cours de création…

SampleModelBean (Session): Bean utilisé pour la gestion des patterns utilisés pour la création des samples : NamePattern, OriginalNamePattern..

UserBean (Request): Bean pour la création des utilisateurs

UserSessionBean (Session): Bean utilisé pour la gestion de l'utilisateur courant : coordonnées et liste des échantillons de travail ( a revoir)

ProcessedSampleBean Bean représentant un échantillon et des informations annexes : nombre et liste des acquisitions, liste des process/demandes subis et dernier process….

ProcessStepBean Bean représentant un “process” au sens large. Un process pouvant être un protocol_application ou une demande de passage en masse ou au robot. Ce bean est dérivé en autant de bean que de process différents

SamplesCacheBean(Session): Bean utilisé pour la gestion des échantillons pour une étude données. Un cache est utilisé pour le temps où une même étude est sélectionnée. Ce bean gère la liste des échantillons en fonction de leur dernièr process. C'est également ce bean qui gère la taille des éléments par page pour les listes des échantillons / acquisitions

SampleToAnalyseBean(Request) : Bean utilisé pour le passage du statut d'un sample a “en attente d'acq” : le temps de la validation des infos. Dans le cas d'un échantillon seul.

SamplesModifierBean (Session): Bean utilisé pour la modification des propriétés de plusieurs échantillons (d'une même étude) : statut (depuis la page liste des échantillons) ou paramètres relatifs au planning en masse (depuis la page liste des échantillons planifiés)

Figure 6 : Diagramme de classes de Gestion des échantillons et des process associés.

Il existe plusieurs listes d'échantillons correspondant chacune à un critère : Liste des échantillons en attente d'acquisition ou de passage robot de l'utilisateur en cours indépendement de l'étude d'appartenance, Liste des échantillons d'une étude donnée, Liste des échantillons en fonction du dernire process subi d'une étude donnée, ….

Voici le schéma globale de l'organisation des pages JSF et des Backing Beans concernant la manipulation de ces listes:

A REFAIRE !!!

Cette liste est affichée par la page subView_study_samples.jsp (incluse dans la page view_study). La liste est gérée par SamplesCacheBean. Les objets de cette liste sont des ProcessedSampleBean. Aucune modification sur les échantillons nr'est possible depuis cette page. Sauf peut etre le changement de status ⇒ available a consumed.

• StudyBean et la page sample_edit_attribute.jsp : Modification des échantillons sélectionnés ou de tous les échantillons
• ProcessedSampleBean : modification de l'échantillon représenté par le bean.

Cette liste est affichée par la page subView_study_process.jsp. (include dans viex_study), elle est également gérée par SamplesCacheBean. Le choix du process visualisé est géré par SamplesCacheBean. Une méthode

• Pour un ensemble d'échatillons (tous ou ceux sélectionnés) par l'intermédiaire bu bean StudyUtilBean et la page sample_edit_attribute.jsp qui affiche uniquement les attributs modifiables en fonction de la commande d'origine (lien “modification du type d'instrument ou lien modification du commentaire…)
• Pour un échantillon donné par l'intermédiaire du bean StudySampleBean.

Cette liste est affichée par la page subView_study_process.jsp. (include dans viex_study), elle est également gérée par SamplesCacheBean. Le choix du process visualisé est géré par SamplesCacheBean. Une méthode

• Pour un ensemble d'échatillons (tous ou ceux sélectionnés) par l'intermédiaire bu bean StudyUtilBean et la page sample_edit_attribute.jsp qui affiche uniquement les attributs modifiables en fonction de la commande d'origine (lien “modification du type d'instrument ou lien modification du commentaire…)
• Pour un échantillon donné par l'intermédiaire du bean StudySampleBean.

Cette page, subView_user_samples.jsp, affiche la liste de tous les échantillons en attente d'acquisition de l'utilisateur. Elle récupère la liste de ces échantillons du bean UserSessionBean. Il est possible de modifier le status d'un échantillon donné par :

• StudySampleBean : modification de l'échantillon représenté par le bean.
  • SampleToAnalyseBean : Dans le cas ou le status de l'échantillon devient “a analyser” la page change_available_sample_status.jsp est affichée (dans une popup) afin de permettre la saise des informations relatives à la plannification en masse. ces informations sont sauvegardées dans SampleToAnalyseBean tant que la validation n'est pas effective.

La création se fait en 3 étapes :

• Création de l'origine biologique + spécification nombre d'échantillons :

o Utilisation des beans SamplesReceptionBean pour les fichiers attachés notament; et BiologicOriginBean

• Création des échantillons

o Utilisation des beans BiologicOriginBean et SamplesReceptionBean pour visualiser le choix fait en 1. et SamplesReceptionBean pour la création des échantillons, SampleModelBean pour la saisie automatique

• Récapitulation des informations et validation :

o Utilisation des beans BiologicOriginBean et SamplesReceptionBean pour l'affichage des informations précédement saisies.

Nota : à chaque navigation dans ces étapes (exemple : changement d'étape, saisie automatique, navigation dans les échantillons existants, etc…) les Validator des noms des échantillons, nom originaux etc… sont appelé, pour savoir si ils doivent valider les valeurs correspondantes il y a un test sur 2 paramètres de la requête : ORIGIN_PARAM et SCROLL_PARAM.

Figure 7 Diagramme de navigation JSF entre les différentes pages