Neogia ====== :Author: Benjamin Poussin :Revision: $Revision: 1.1 $ :Date: $Date: 2004/04/29 15:02:47 $ .. sectnum:: .. contents:: Sommaire Internationnalisation des labels -------------------------------- Lors de la génération de label, le texte est celui du chemin complet du label, un fichier de traduction par defaut assigne le nom a ce chemin. Il est possible dans les fichiers de traduction de raccourcir le chemin pour utiliser la meme traduction pour plusieurs label. par exemple si on a les chemins suivants:: i18n._("org.codelutin.nereide.product.description") i18n._("org.codelutin.nereide.stock.description") Le fichier généré par défaut sera i18n-nereide.properties:: org.codelutin.nereide.product.description=description org.codelutin.nereide.stock.description=description Si l'on souhaite utiliser la meme traduction pour les deux, il faut raccourcir le chemin dans les fichiers de traduction i18n-properties-fr_FR.properties:: description=description Le fonctionnement est le suivant, on demande la traduction de org.codelutin.nereide.product.description, si l'on ne trouve pas de traduction on que celle-ci est vide on recherche la traduction de codelutin.nereide.product.description et ainsi de suite jusqu'a ce que l'on trouve une traduction ou que l'on n'arrive a une chaine vide a traduire. Dans ce cas on reprend la valeur qui se trouve dans le fichier i18n-nereide.properties pour le label. Internationnalisation des attributs ----------------------------------- Certains attributs doivent pouvoir être traduit. Pour cela on reprend l'idée de Glasnost avec un serveur de traduction. Mais comme certaine chaîne doivent pouvoir avoir plusieurs traduction en fonction de l'endroit ou il se trouve. L'idée est d'avoir une traduction par défaut puis des traductions spécifique par endroit d'ou la chaine provient. La premiere traduction faite devient la traduction par defaut. Lorsque l'on recherche une traduction pour un autre attibut alors on recherche s'il existe une traduction specifique pour une attribut donné, si ce n'est pas le cas, on prend la traduction par defaut. Génération de valeur d'attribut ------------------------------- tag-value auto avec un pattern Typage des attributs -------------------- pouvoir mettre en tag value le pattern de saisie de l'attribut:: pattern=price puis dans un fichier de configuration de pattern:: price=#+,## Ce pattern peu varier suivant l'utilisateur (langue de l'utilisateur). Peut-être mettre ca dans la table de traduction. Attributs des Entities ---------------------- Il faut pouvoir ajouter a l'exécution des attributs à une entity. Ces champs servent à la saisie, lecture et recherche, mais n'entre jamais dans du code métier. :remarque: En fait on pourrait faire ca pour pratiquement tous les champs et si en plus le language d'écriture des méthodes métiers est du python ou un autre langage souple, il serait possible d'écrire directement:: entity.attoptionnel = ... Attributs de type enumeration ----------------------------- Il faut pouvoir avoir des types énumérations. Ces types doivent pouvoir être traduit. On gère les attributs énumérations comme les patterns, c-a-d que l'attribut à un type String, boolean, ... et un tag-value qui donne le nom de l'énumération à utiliser:: enum=projectStatus La valeur des énumérations est conservé dans un fichier de configuration qui peut-etre surchargé par des valeurs dans une table en base de données:: projectStatus=a faire, fait, fini Attribut chaine de caractères ----------------------------- Les attributs de type chaine de caractères ne sont pas internationnalisé par défaut, il faut mettre un champs tag-value pour la faire reconnaitre comment internationnalisable:: i18n=true Attribut historisable --------------------- Il faut pouvoir monitorer un attribut, il faut lorsque la valeur est modifié on conserve (user, date, oldValue, newValue). Il faut aussi une méthode supplémentaire getHistory[Attribut]():list Classe d'association daté ------------------------- Si une classe d'association a deux attributs:: fromDate: date throwDate: date alors on génère une méthode isValidDate(date):true sur la classe d'association. Et sur l'entité une methode get[Attribute](date) qui ne retourne les valeurs valide pour une date donnée. Attribut a ajouter a toutes les entitees ---------------------------------------- dernier utilisateur ayant modifie l'entity, date de modif, date de creation, numero de version Hook sur les services --------------------- A partir d'uml on génère une interface pour les services, le développeur implante le service, et le déclare dans le fichier de propriété du context. Lorsque l'utilisateur demande un service, le service instancier est celui implanté par l'utilisateur il est alors encapsulé dans un ProxyHook, qui permet d'enregistrer des objets avant et apres l'appelle reel de la methode du service:: addPreHook(String methodeName, TopiaHook o) addPostHook(String methodeName, TopiaHook o) TopiaHook --------- call(String methodeName, Object[] arguments, Object result): Object TopiaHook est un objet avec une methode call, qui sera appele avec le nom de la methode et les arguements de la methode, si l'object est enregistre pour le post l'argument result peut avoir la valeur resultante de l'appel reel de la methode si la methode retourne une valeur ou null. Le proxy doit pouvoir être paramètré pour pouvoir activer ou désactiver l'appel au méthode:: callPre: boolean callMethode: boolean callPost: boolean :remarque: ne serait-il pas possible de faire de l'AOP pour ca ? Interaction avec OfBiz ====================== Lors de la creation, delete d'une entity dans OfBiz, un ECA enregistre dans Neogias l'id de l'entity. Lorsque l'on a besoin d'un objet OfBiz dans Neogia on demande au CRUD existant sur lequel on a ajouter un TopiaHookProxy avec des TopiaHook en post sur les methodes de recherches. Ces Hook prennent les idees des objets qui devrait normalement etre retourne et demande a OfBiz les objets reels qui ont ces id. On retourne donc des objets OfBiz. Il faudra faire attention avec les methodes qui retourne des objets et non des listes. Dans OfBiz pour utiliser un objet Neogia, on demande a TopiaContext une instance du context en lui passant le fichier de propriete. Vu que le fichier de propriete sont les memes que pour le context existant dans neogia, c le meme context qui est retourne. Schema XMI ========== Pour pouvoir travailler a plusieurs sur l'ensemble de la modélisation chaque module sera modélisé dans des fichiers séparés. Lorsque l'on a besoin d'une entity d'un autre module on crée un classe du même nom stereotype <>. Il n'est pas authorisé de faire autre chose que des liens sur les objets extern (ajout d'attributs, ajout de méthode, ...). Pour faire cela il faut demander au mainteneur principale qui sert à certifier la cohérence de l'ensemble de son module avec les interations avec les autres modules Lors de la lecture des fichiers XMI, si une entity externe est lu mais qu'aucune autre entity non extern porte le même nom alors une erreur est levée.