Documentation développeur

Environement de développement

Présentation

L'environnement de développement de l'application web Chorem se découpe de la façon suivante :

• d'un site en production : c'est l'espace où l'on trouve une version du logiciel en utilisation réelle;
• d'un espace de gestion du projet : c'est l'espace commun à l'ensemble des développeurs pour le partage des sources;
• de postes de développement : c'est l'espace propre à chaque développeur pour faire avancer le projet.

Voici le détail de chaque partie : Site en production : Intranet Espace de gestion du projet : Labs

Poste de développement : Eclipse

Légende :

• Serveur d'application centralise les applications web;
• Labs est un dépôt pour l'ensemble des projets permettant la gestion des bugs, des versions, des demandes de nouvelles fonctionnalités, ...
• Eclipse est un environnement de développement regroupant de nombreux outils;
• CVS permet le gestion des versions des sources;
• Maven 2 automatise les tâches de compilation, de test, de packaging, ...
• Postgresql est une base de données.

Mise en marche

Les étapes suivantes sont nécessaire pour pouvoir débuter dans le projet Chorem :

1. Création d'un compte sur le Labs
2. Inscription sur le projet Chorem (liste de diffusion)
3. Installation de Maven 2
4. Récupération du projet

Architecture technique

Présentation

Le projet Chorem est ambitieux en terme de technologie en embarquant les toutes dernières :

• J2EE : pour JAVA 2 Entreprise Edition, apporte les technologies autour des servlets et des javaServer Pages (JSP). Elles définissent la mise en place d'une application JAVA permettant de générer dynamiquement des données au sein d'un serveur HTTP. La librairie JSTL (Java Standard Tag Library) est utilisé pour faciliter la création de page JSP.
• MVC : pour Model-View-Controller, est un patron de conception pour le développement d'application logicielles qui sépare le modèle de données, l'interface utilisateur et la logique de contrôle. Cette architecture est utilisée dans Chorem et est renforcée par l'utilisation des frameworks, Mentawai et ToPIA.

• Hibernate : est un framework générant la persistance des objets en base de données relationnelle. Chorem l'utilise par le biais d'un autre framework, ToPIA.
• AJAX : pour Asynchronous JavaScript And XML, permet de passer une requête au serveur sans avoir le besoin de recharger la page. Des composants AJAX sont utilisés dans Chorem, ils sont basés sur le framework ZK. Il propose un ensemble d'outils pour la construction de composants AJAX.

L'architecture technique pose deux difficultés majeures sur le projet Chorem :

• la compréhension : l'utilisation et le positionnement des technologies dans le projet
• la fédération : l'articulation et la communication entre les technologies

Règles de codage

Surtout regarder ce qui a été fait pour s'en inspirer. Encodage

• Tous les codes sources doivent être en ISO-8859-15, sans tabulation, avec 4 espaces (paramètres à positionner sur Eclipse).

Formatage du code

• Utiliser systématiquement le formatteur avec les paramètres par défaut d'Eclipse sur les fichiers Java. Ne jamais commiter un fichier non formatté : les mises en formes futures apparaîtraient comme des différences cachant les vraies modifications de version à version.
• Mettre l'en-tête standard dans tous les fichiers sources. Récupérer le fichier codetemplates.xml à la racine du projet sous CVS, et l'importer dans Eclipse (Window -> Preferences -> java -> Code Style -> Code Templates).
• Mettre des accolades ouvrantes et fermantes pour tout bloc, même pour 1 ligne.

Règles de nommage

• Les règles de nommage doivent respecter les règles définies par Sun
• Ne pas écrire les méthodes des accesseurs à la main. Les générer avec Eclipse.

Documentation

• Chaque méthode doit être clairement décrite dans la javadoc. Utiliser cet emplacement pour décrire les préconditions d'appel de la méthode.
• Optimiser les commentaires : ils doivent permettre de naviguer plus rapidement dans une méthode en la découpant en unités de traitements. Exemple : remontée des informations, Parcours de la liste remontée pour en extraire les informations utiles, ... sont des commentaires ayant la granularité adéquate. Un commentaire par ligne rend le code illisible. Des commentaires supplémentaires doivent être ajoutés pour expliciter les points «difficiles» du code (algorithmes, code «technique», ...).

JSP

• Ne pas utiliser le tag <table> à part pour l'affichage de réels tableaux. Utilisez le CSS pour le positionnement.
• Ne pas utiliser l'attribut style dans les balises html sauf s'il est avéré que ce style est spécifique à la page en cours et ne sera pas utilisé ailleurs.
• Pour savoir quel style appliquer à votre besoin, consultez le responsable des feuilles de style du projet. Le cas échéant, il est la seule personne qui a le droit d'écrire de nouveaux styles.
• Toujours spécifier la taille des images affichées dans les tableaux pour une plus grande rapidité d'affichage (calcul de dimensionnement des cellules facilité)
• On ne doit pas trouver de code Java dans les JSP pour des raisons de facilité de deboguage et de maintenance. Les taglibs sont assez puissants pour couvrir tous les besoins de l'application.
• N'utiliser JavaScript qu'en cas d'absolue nécessité. Le cas échéant, tester son exécution dans Mozilla et IE.
• Utiliser les méthodes JavaScript de main.js disponibles par défaut sans import pour toutes les pages héritants d'une layout prédéfinie. On y trouve entre autres les méthodes de soumission de formulaire avec ou sans paramètre.
• Commentaire jsp. Evitez les <!- mon commentaire -> qui sont visibles dans le code source. Utilisez plutôt <% //mon commentaire %> qui ne seront pas visibles par l'utilisateur final.

Logs

• Utilisez les logs de commons-loggin. Pour tout ce qui est log dans le programme, il ne faut pas utiliser System.out.println ou System.err.println.

Déclaration :

private static final Log log = LogFactory.getLog(MyClass.class);

Utilisation :

if (log.isDebugEnabled()) {
  log.debug("blablabla");
}

Fichiers et répertoires

Module

Un module est découpé en trois parties, le contrôleur, la vue et le modèle.

Contrôleur : src/java

• moduleName
  • nameEntité - répertoire créer pour chaque entité du modèle
    • action - généralement contient les fichiers suivants
      • FindIdNameEntité - pour la recherche d'une entité
      • FindAllNameEntité - pour la recherche de l'ensemble des entités
      • UpdateNameEntité - pour la création et la modification d'une entité
      • DeleteNameEntité - pour la suppression de l'entité
  • usecase - répertoire contenant les fichiers de définition des cas d'utilisation (comportement des pages)
  • Manager.java - fichier contenant l'ensemble des déclarartion des pages et des actions

Vue : src/webapp/WEB-INF

• moduleName
  • commun - partie commune à l'ensemble des pages du module
    • zulComponent - répertoire avec les composants ZK
    • lang - fichiers de langue
    • menu.jsp - menu du module
    • properties.jsp - propriétés du module
  • nameEntité - répertoire créé pour chaque entité du modèle généralement contient les fichiers suivants
    • list.jsp - liste des entités
    • view.jsp - visualisation d'une entité
    • form.jsp - formulaire pour la création et modification d'une entité
    • monitoring.jsp - page de reporting sur l'entité

Il existe un répertoire contenant les éléments communs à l'ensemble des modules dans src/webapp/WEB-INF/common. On y trouve : le layout, les messages, la barre d'adresse et les propriétés communes.

Modèle : src/xmi

Le modèle est fait sur ArgoUML, le fichiers se trouve dans le répertoire src/xmi :

• chorem.zuml : fichier ArgoUML avec les modèles
• chorem.properties : propriétés supplémentaires sur le modèle pour ToPIA

Autres

Toutes les éléments ajoutés à Mentawai se trouve dans le paquetage AddOn. Fichier de configuration :

• src/resources (répertoire) pour ToPIA
• pom.xml pour maven 2
• web.xml pour l'application web (filtre, mentawai, ZK)

Les fichiers de style se trouve dans src/webapp :

• layout.css : style du layout
• general.css : style des pages
• zk.css : style pour les composants ZK

ClassPath

Il est nécessaire de rajouter dans le classe path :

• src/java : source java
• src/gen/java : source java généré par ToPIA
• src/test : test unitaire
• src/resources : les ressources
• src/webapp/WEB-INF/<module>/lang : les fichiers de langue de chaque module

Mentawai

Mentawai est basé sur trois notions :

• Manageur, il regroupe l'ensemble des actions avec leurs enchaînements.
• Action, elle permet de définir les traitements à effectuer.
• Conséquences, elle permet au manageur de spécifier le traitement à effectuer après l'exécution de l'action (redirection, forwarding, enchaînement d'action).

Voici le déroulement au niveau du serveur d'application de la réception d'une requête :

1. Une requête est reçue par le manageur
2. Une action est déclenchée
3. L'action est exécutée et peut manipuler la base de données
4. Un code de retour est envoyé par l'action au manageur
5. La conséquence appropriée est levée
6. Soit une nouvelle action est déclenchée (retour au point 3)
7. Soit une nouvelle page est envoyée au navigateur

Explication

Modèle

Présentation des modèles

Les modèles de Chorem spécifient l'ensemble des entités métiers de chaque domaine (gestion de projet, gestion des contacts, comptabilité, ...). Dans l'ancienne version de Chorem, ils ne comportaient pas les renseignements nécessaires pour l'expression des besoins et étaient complexes. Un travail de simplification a été effectué, seules les données nécessaires ont été conservées et ajoutées. Dans le cas de Chorem, chaque modèle de données correspond à un module, il n'existe pas de modèle global pour l'ensemble des modules. Cela permet une clarté et une lisibilité accrues. Les parties contrôleur et vue n'ont pas été spécifiées parmi les modèles. Il a pourtant été pensé de les spécifier pour pouvoir les générer. Par manque de temps et vu la complexité de la tâche, cette idée a été abandonnée. Partie commune de Chorem : Modèle gestion de contacts : Modèle gestion de projet : Modèle comptabilité :

Génération avec ToPIA

Le framework ToPIA permet dans le projet Chorem de générer la partie métier de l'application, c'est à dire les classes JAVA ainsi que le mapping Hibernate pour la persistance. Cela représente un travail considérable en moins pour le développeur et une flexibilité importante dans les évolutions futures de la partie métier. L'utilisation du framework ToPIA se découpe en plusieurs phases, elles sont itératives :

1. Création du diagramme de classe sous ArgoUML par exemple
2. Exportation du modèle en XMI
3. Génération des fichiers JAVA et Hibernate par ToPIA
4. Codage des méthodes non implémentées

Intégration ToPIA et Mentawai

Bien que Mentawai et ToPIA soient développés chacun de leur coté, Mentawai a du utiliser ToPIA pour accéder aux données. La communication entre les deux frameworks est faite par un mécanisme proposé par Mentawai. Il permet de transformer automatiquement les champs d'un formulaire en un objet par le biais d'un filtre. Ce procédé est ainsi appliqué sur les objets générés par ToPIA. Deux filtres Mentawai ont été developpés :

• un pour la gestion d'un bean ToPIA
• un pour la gestion des beans ToPIA par ajout d'une annotation java directement dans l'action

Exemple d'action :

public class TaskDelete extends ElementaryAction {
  @TopiaBean
  private Task task;
  public void action() throws Exception {
    task.delete();
  }
}

La récupération d'une entité se fait par rapport à un identifiant topia (topiaId) stocké dans un formulaire. Quatres cas sont possibles lors d'une récupération :

• l'identifiant est précisé et la récupération n'est pas précisé alors l'entité est recherchée et chargée depuis la base de données par rapport à l'identifiant.
• l'identifiant est précisé et la récupération est précisé alors l'entité est recherchée et chargée depuis la base de données par rapport à l'identifiant et les attributs de l'entité sont remplacés par les valeur contenu dans le formulaire.
• l'identifiant n'est pas précisé et la récupération est précisé alors l'entité est créée et les attributs de l'entité vaut les valeurs contenues dans le formulaire.
• l'identifiant n'est pas précisé et la récupération n'est pas précisé alors rien est fait.

La récupération est à préciser dans l'annotation TopiaBean par le paramètre «recupération». Exemple : Entité ToPIA :

class Test {
  String topiaId;
  int unAttribut;
  ...
}

Formulaire :

<form action="actionTest.mtw">
  <input type=hidden name=testId value=topiaIdvalide>
  <input type=hidden name=unAttribut value=99>
  ...
</form>

Action :

public class ActionTest extends ElementaryAction {
  @TopiaBean(recuperation=true)
  private Test test;
  public void action() throws Exception {
    test.update();
  }
}

Résultat : L'entité «topiaIdvalide» va avoir comme valeur «99» pour l'attribut «unAttribut» après validation du formulaire.

Transaction

Les actions de Mentawai sur ToPIA doivent être effectuées dans une transaction. Il a été choisi de créer un filtre (Mentawai). Il permet de lancer la transaction et de réaliser un commit en cas de succès ou un rollback en cas d'échec de l'action. La transaction est récupérable depuis les actions Mentawai pour pouvoir faire des traitements plus complexes. Dans ToPIA, la transaction correspond à un contexte dans lequel on manipule nos entités.

Multi-base

Suivant le nom du serveur un fichier de propriété complète le fichier par défaut. Cela permet de modifier à la voler la base de données sur laquelle on travaille. En fait, on a une instance de Chorem pour une multitude de base de données. Les fichiers de propriétés sont chargés une fois et stockés dans la session de l'utilisateur. On associe aussi la transaction en cours avec le fichier de propriété. Cette gestion multi-base est réalisée dans le fitre Mentawai des transactions.

Interface

Layout

Le layout définit l'agencement des pages du site. Dans le cas de Chorem, les parties concernées sont celles vues précédemment. La gestion du layout consiste à positionner automatiquement les parties. Aucune gestion du layout n'est proposée dans Mentawai, il a donc fallu pallier à ce manque. Deux possibilités ont été envisagées, utiliser un nouveau framework comme Tiles ou développer un système de layout. La deuxième solution a été retenue, car elle apporte une solution simple et efficace à cette gestion. Le système de layout développé repose sur les feuilles de style (CSS) et les filtres (servlet). Les feuilles de style permettent de positionner les parties, et les filtres permettent d'ajouter les parties manquantes à la réponse (au corps). Voici l'algorithme du filtre :

1. Injecte les propriétes communes dans la requête
2. Interprétation du body
3. Enregistre l'interprétation du body dans la requête sous forme d'un attribut
4. Interprétation du layout en utilisant comme body l'attribut enregistré
5. Retourne la réponse au client

Ergonomie

L'ergonomie consite à adapter le système informatique à son utilisateur. Le nombre de données et d'actions a complexifié l'ergonomie de Chorem. Pour obtenir une ergonomie convenable, les règles suivantes ont été appliquées :

• rapide : le temps de réponse du site doit être minimal
• simple : le graphisme ne doit pas nuire au contenu
• universel : le site doit être multi-langues
• navigable : la navigation doit être agréable et facile
• testé : le site doit être testé en terme de technique et d'ergonomie

Chorem est compatible FireFox 1.5. Il reste quelques points à revoir pour être aussi compatible Internet Explorer.

Exception

La gestion des exceptions se fait aussi par une servlet filtre. Elle intercepte toutes les exceptions et redirige vers la page des exceptions. Selon les exceptions, un message clair doit être afficher à l'utilisateur (à faire).

Internationalisation

Pour réaliser l'internationalisation, la librairie JSTL a été préférée à la solution Mentawai. Le bundle JSTL est déterminé dans le fichier propiétés communes. À un module correspond un fichier de langue. Il existe un fichier de langue commun, il regroupe les traductions commune à l'ensemble des modules, c'est à dire l'ensemble des noms des boutons, des explications des erreurs, des noms des modules,... Utilisation dans les JSP : Pour récupérer la traduction dans le bundle du module :

<fmt:message key="..."/>

Pour récupérer la traduction dans le bundle commun :

<fmt:message bundle="${commonBundle}" key="..."/>

Actuellement la langue (français, anglais, ...) est stockée dans le cookies, à terme elle devra être dans les préférences utilisateur.

Message

La gestion des messages se fait par le mécanisme proposé par Mentawai. Plusieurs ajouts ont tout de même été fait :

• la partie message d'erreur a été complétée pour pouvoir gérer des types d'erreur.
• en cas de message d'erreur, les messages informatifs sont supprimés.

Au niveau des JSP, les messages renvoyés par Mentawai sont des clés pour les fichiers de langues. Le cas des messages d'erreur est particulier. La clé est composé de deux parties, une partie pour le champ, une partie commune explicatif de l'erreur. Exemple de message d'erreur : Clé du message : required.error.name Champs : required.error.name = ... (message) Explication : required.error = ... (message) La gestion des messages est à inclure dans chaque page, elle n'appartient pas au layout. La page d'header a la charge de la gestion des messages. Inclure la page d'header :

<jsp:include page="${headerPage}"/>

Barre d'adresse

La barre d'adresse est un historique des navigations dans le site. Elle est retenue dans la session sous la forme d'une map : nom -> lien. La barre d'adresse ne fait pas partie du layout car elle est rempli par passement de paramètre à la page d'header. Inclure la page d'header :

<jsp:include page="${headerPage}"/>

Inclure la page d'header avec passement des paramètres pour la barre d'adresse :

<jsp:include page="${headerPage}">
  <jsp:param name="addressBarName" value="nom du lien"/>
  <jsp:param name="addressBarURL" value="url du lien"/>
</jsp:include>

Contrôleur

Cas d'utilisation

Comme tout framework, Mentawai a des lacunes, la plupart concerne le manageur, les voici :

• enchainements de pages de bas niveau;
• réutilisabilité limitée;
• lisibilité du manageur;
• maintenance difficile, pas d'approche modulaire au niveau du manageur.

De plus, Mentawai ne permet pas de répondre à deux problèmes classiques d'une application web :

• bouton précédent du navigateur
• réutilisation des pages

En contrepartie, Mentawai étant basé sur une approche objet, il a été possible de le complèter. La notion de cas d'utilisation a été introduite. Le manageur de Chorem est composé de plusieurs manageurs, un pour chaque module. Cette fonctionnalité a été rajoutée pour permettre une meilleure lisibilité et le respect de l'approche modulaire.

Bouton précédent

Le retour à la page précédente n'est pas contrôlé et peut entrainer des incohérences. Il n'existe pas de solution efficace à ce type de problème. Peu de frameworks proposent une solution. Le dernier framework JBoss Seam est un des seuls à en proposer une. Exemple : Scénario :

1. L'utilisateur se trouve actuellement sur la page 1.
2. Il passe à la page 2 par le lien 1 en enregistrant des données au niveau de sa session.
3. Il quitte la page 2 avec le bouton précédent du navigateur (sans renvoyer de requête au serveur).
4. Il passe à la page 3 par le lien 2. Les données enregistrées au niveau de la page 2 sont alors accessibles au niveau de la page 3. Auncun contrôle ne peut être effectué. Pour la page 3, cela peut poser des problèmes de cohérences.

Deux stratégies sont possibles pour répondre au problème du back button :

• continuer à conserver les données dans la session. Mais il est nécessaire d'avoir des informations supplémentaires, au minimun le nom des pages pour lesquelles sont destinées les données. L'inconvénient majeur de cette stratégie est de savoir à quel moment supprimer les données en session.
• passer les données par la requête d'une page à l'autre, au risque de surcharger les requêtes.

La gestion des cas d'utilisation nécessite le stockage d'un contexte d'exécution. Il regroupe de nombreuses informations et doit être conservé tout le long de la navigation dans le site. Une incohérence dans le contexte impliquerait un comportement de page incorrect. La deuxième stratégie a été mise en place pour le stockage du contexte. Seulement les informations invariables ou non sensibles sont stockées dans la session. Par ce principe, en cas de retour sur le navigateur, le contexte précédent est automatiquement utilisé, car la page contient elle même le contexte. Il a été développé un tag JSP (avec JSTL) spécial pour inscrire mécaniquement le contexte dans les formulaires.

Réutilisation des pages

La réutilisation des pages est maximisée dans Chorem pour minimiser la maintenance et le temps de codage. En effet, des pages peuvent être réutilisées plusieurs fois et avoir un comportement différent. Il existe deux moyens pour réutiliser une page :

• la page peut être appelée dans des places différentes du site, exemple un formulaire peut servir à la fois en modification et en création.
• la page peut être inclue dans une autre, exemple une liste d'éléments.

Il faut pouvoir répondre à toutes les exigences de réutilisation des pages dans la gestion des cas d'utilisation.

Définition

Les cas d'utilisation essaient de pallier aux inconvénients et les manques de Mentawai. Son principe est de spécifier pour chaque utilisation d'une page son comportement. En effet, un enchaînement de page est un automate non-déterministe avec comme état, les pages web et comme transition, les liens. La difficulté est de rendre cet automate déterministe. Le seul moyen est de rajouter un état supplémentaire aux pages, le cas d'utilisation. Exemple : Deux comportements sont possibles après validation du formulaire. Soit l'utilisateur retourne à la liste en cas de création d'un nouveau élément. Soit il retourne en visualisation en cas de modification d'un élément. Le schéma suivant montre l'automate précédent déterminisé par les cas d'utilisation :

Fonctionnement

Il est nécessaire de connaitre les informations contenues dans les cas d'utilisation pour comprendre leur fonctionnement.\\ Voici ces informations :

• le point d'entrée, est la première page affichée lors d'une invocation du cas d'utilisation;
• les paramètres à conserver, permettent de conserver des données d'une page à une autre;
• le déplacement d'une page à une autre, définit un déplacement de page dans un même cas d'utilisation;
• déplacement d'un cas d'utilisation à un autre, définit un déplacement entre cas d'utilisation;
• le contexte, conserve les informations d'exécution.

La figure suivante met en évidence les différentes informations stockées pour un cas d'utilisation sur un exemple simple, une action permettant d'aller d'une page à une autre : Le fonctionnement des cas d'utilisation suit toujours les étapes suivantes :

1. Réception d'une requête
2. Récupération du contexte
3. Exécution des actions liées à la demande de l'utilisateur (ajout, suppression, modification, ...)
4. Détermination du cas d'utilisation en cours par le manageur.
5. Détermination du prochain saut (page ou nouveau cas d'utilisation) par le cas d'utilisation en cours
6. Exécution des actions liées à l'affichage de la prochaine page
7. Modification et sauvegarde du nouveau contexte
8. Affichage de la page

Exemple

Création du cas d'utilisation :

public class NomDuCasDutilisation extends UseCase {

public String NomD1CasDutilisation() throws Exception {

accessPoint(NomDeLaPremièrePage, ParamètresAConservés)

.move(ActionMentawai, NomDeLaProchainePage) .move(AutreActionMentawai, NomDuProchainCasDutilisation);

access(NomDeLaProchainePage, ParamètresAConservés)

.move( ...

return super.execute(); }

public String NomDuProchainCasDutilisation() throws Exception {

...

} } Déclaration auprès du manager :

public class Manager extends org.codelutin.chorem.web.mentawai.Manager {

public static String NomD1CasDutilisation = AdresseDuCasDutilisation; public static String NomDuProchainCasDutilisation = AdresseDuCasDutilisation; public static String ActionMentawai = AdresseDeLactionMentawai; public static String AutreActionMentawai = AdresseDeLactionMentawai; public static String NomDeLaPremièrePage = CheminDeLaPageJSP; public static String NomDeLaProchainePage = CheminDeLaPageJSP;

public void loadModules() {

... // Déclaration des cas d'utilisation createUseCase(NomD1CasDutilisation, NomDuCasDutilisation.class); createUseCase(NomDuProchainCasDutilisation, NomDuCasDutilisation.class); // Déclaration des adresses avec les actions liées à la demande de l'utilisateur (ajout, suppression, modification, ...) createFirstLine(ActionMentawai, ListeActions); createFirstLine(AutreActionMentawai, ListeActions); // Déclaration des JSPs avec les actions liées à l'affichage de la page createLastLine(NomDeLaPremièrePage, ListeActions) createLastLine(NomDeLaProchainePage, ListeActions) ...

} }

Validation

La validation des données est déclarée au niveau des actions. Une méthode a été rajoutée (addRule) pour simplifier la déclaration des règles de validation. En cas d'erreur de validation la dernière page est affichée. Il est possible de rajouter des régles de validation. Pour la gestion des messages d'erreur, allez voir la partie sur les messages. Attention il ne faut pas mettre de validation au niveau des actions pour l'affichage d'une page JSP, cela provoque un bouclage sur l'action. Exemple d'action avec validation :

public class uneAction extends ElementaryAction implements Validatable {
  public void action() throws Exception {
    ...
  }
  public void initValidator(Validator validator, String innerAction) {
    addRule(validator, "nomDuChampAValider", TypeValidator.typeDeValidation);
    ...
  }
}

Principaux type de validation :

• REQUIRED : champ requis
• TIME : champ au format temps
• DATE : champ au format date
• CURRENCY : champ au format monétaire
• XOR : soit l'un soit l'autre
• WEEKYEAR : semaine et année valide
• LEDATE : date supérieur ou équale à une autre date
• EQUALS : equalité entre deux champs
• DUPLICATE : champ dupliqué

Conversion

La conversion des données est déclarée au niveau des actions. Elle se fait après la validation des champs. Il est possible de rajouter des règles de conversions. Aucune modification du mécanisme proposé par Mentawai n'a été fait. Il est envisageable d'apliquer le même principe que pour la validation. Exemple d'action avec conversion :

public class uneAction extends ElementaryAction implements Convertable {
  public void action() throws Exception {
    ...
  }
  public void initConverters(Map converters, String innerAction) {
    converters.put("nomDuChampAValider", new UnConvertisseur());
    ...
  }
}

Sécurité

Le framework ToPIA apporte un système de sécurité basé sur JAAS (Java Authentication and Authorization Service). Le système permet la gestion des authentifications et des autorisations. Cette approche a été préférée à celle proposée par Mentawai. En effet, la gestion des accès avec ToPIA se fait sur les entités du modèle. Contrairement à Mentawai qui limite l'accès sur les pages et ne repose pas sur JAAS. Ainsi le contrôle d'accès est plus proche des données et rend l'application plus sécurisée. En cours de développement

Reste à faire

Veuillez consulter la suivi du projet : http://labs.libre-entreprise.org/tracker/?group_id=41 Des tâches restent toujours d'actualité :

• Créer de nouveau module
• Complèter la documentation
• Ajout de fonctionnalités diverses dans les modules existants
• Amélioration du style
• Amélioration de la partie contrôleur