Index: topia/doc/besoin.rst diff -u /dev/null topia/doc/besoin.rst:1.1 --- /dev/null Mon Aug 2 17:57:24 2004 +++ topia/doc/besoin.rst Mon Aug 2 17:57:19 2004 @@ -0,0 +1,202 @@ +Neogia +====== + +:Author: Benjamin Poussin +:Revision: $Revision: 1.1 $ +:Date: $Date: 2004/08/02 17:57:19 $ + +.. 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.