- Topia-devel - mailman.cloud.codelutin.com

divers questions
by olivier heintz May 14, 2004

May 14, 2004

tout d'abord des informations : avec les nouvelles versions nettement plus rapide pour ofbiz-neogia : avant 3mn maintenant 18s. Question : a) dans ofbiz-neogia, il appel toujours lutingenerator-0.6.jar, donc pour l'instant j'ai fait un lien vers la version 0.8 !!! b) dans ofbiz-neogia, le build lance la compile java du projet à la fin, ce qui n'a pas d'intérêt dans notre cas, sur les conseils de benj j'ai remplaçé jar:jar par topia:build dans maven.xml mais ça ne change rien. c) dans un générateur, j'ai besoin de tester si un attribue est une association ou un type de base, pour l'instant je teste si son type contient "org", quel serait la bonne méthode. d) y a t'il une différence ou un avantage entre Util.isEntity(clazz) et clazz.hasStereotype("entity") e) lorsque je parcours les attribues d'une classe et que je suis sur une association, comment je peux savoir s'il y a une classe d'association associée. f) les classes qui sont déclarées extern, font bien parties du modele?, je ne les retrouve pas quand je fais un objectModel.getClass(attribue.getType()). ce sera tout pour ce soir Olivier

3 2

usage de la fonction referenceEntity()
by olivier heintz May 13, 2004

May 13, 2004

elle me renvoi toujours false !!!!

1 0

se promener dans le model
by olivier heintz May 12, 2004

May 12, 2004

Bonjour, Je ne trouve pas comment je peux cheminer dans le modéle. Je m'explique a) je parcours toutes les class du modéle b) pour une class je parcours tous les attribues c) pour un attribue qui est une association, comment je récupère l'objet ObjectModelClass correspond au type de l'attribue <= c'est la question d) quand j'aurais eu la réponse, je pourrais parcourir cette class associé pour trouver les attribues que qu'il faut afficher !!! Par avance Merci Olivier

1 0

TODO (v4) ToPIA et lutingenerator
by Cédric Pineau May 12, 2004

May 12, 2004

- Fait : . Optimisation du xsl . Integration de la regle Ant pour le xsl et suppression des xsl dans chaque projet Topia et du skel . Support des attributs calculés . Le contexte est fait. . Les listeners sur les CRUD faits (+ classe ListenerSet dans lutinuntil) . 10% générateurs d'interface uiModel->uiCallbacks et ui , générateur ObjectModel -> uiModel + classe d'implémentation . modifier le ObjectModel pour avoir aussi séparement la description et le complément javadoc (en plus du getDocumentation() qui renvoie tout). Mettre une valeur de retour chaine vide par défaut pour ces trois accesseurs. . Possibilité d'acceder à n'importe quel tagValue au travers d'une methode getTagValue("name") : String - D'ici la fin de la semaine avec benj . Hook sur les services. . mettre en marche le merdier (Pouvoir ecrire une appli qui sauvegarde, effface des entités au travers de l'architecture Topia) . implanter les operations pas abstraites des entités en forward sur services dans les entités . Modifier les listeners sur le principe suivant : le contexte s'enregistre en tant que listener sur tous les CRUD qu'il délivre, les CRUD s'enregistre sur tous les TO qu'ils delivrent. Le code applicatif s'enregistre sur les TO ou les CRUD qui délèguent tous sur le context. Permet d'avoir un lieu unique de events. . Interaction avec OfBiz. - A brève échéance : . Finir l'implantation des classes d'associations . Support des dates de validités sur les classes d'associations fromDate: Date, thruDate: Date -> isValidDate(date):true sur la classe d'association -> get[Attribute](date) sur l'entité qui l'utilise . Supporter correctement les associations bi-direction : A en relation bi-direction avec B, lorsque on lie B à A, B doit etre aussi lié à A de manière automatique. . tests unitaires - Ensuite : . prendre en compte le tag-value i18n avec un pattern sur les attributs. Une table pour toute l'appli. L'idée est de créer un nouveau projet avec la description xmi de ces topia-entités et d'utiliser les generateurs Topia pour les CRUD. On souclassera au besoin ces CRUD pour avoir des operations plus adaptées. ex : i18n=true . prendre en compte la tag-value enumName avec un pattern sur les attributs. ex : enumName=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 Une table pour toute l'appli. . TopiaUser. Une table pour toute l'appli. . prendre en compte la propriete "versioned" des attributs -> stocker l'historique des modifs (user, date, oldValue, new Value) : Une table historique par attribut. -> generer un getHistory[Attribut]():list<History> . pouvoir ajouter des champs à des entités. Une table de description de tagValue (nom, numero d'ordre, type, valeur par défaut) par entité, et une tableur d'instance de tagValue (id de l'entité concernée, nom de l'attribut, valeur). . tag-value value avec un pattern sur les attributs. ex value=now. Il faut maintenant le prendre en compte au moment de la création des TO. le code applicatif utilise la methode create(Interafce de TO) sur le contexte pour creer une instance de TO. Le constructeur du TO interroge le context pour chacun des attributs ayant un tagValue value en lui passant le nom logique, la valeur retournée est un Object, utilisée au travers d'un Statement : new Statement(this, "setAttributeName", context.evalDefaultvalue("value")).execute() . prendre en compte les exceptions déclarées sur les méthodes dans le modèle. . permettre des classes entités abstraites . Implanter les TopiaQuery - Plus tard : . Clone profond . toXML . Automatisation des xmlisation pour l'utilisation dans soot. . Internationnalisation des labels . Internationnalisation des attributs . Intégrer la generation sur des EJB faites par les stagiaires chinois . Generation des UI . prendre en compte le contenu de l'onglet doc des entités et attributs jusqu'au -- pour les tooltips . prendre en compte le mask avec un pattern sur les attributs. ex : mask=price puis dans les fichiers de traductions : price=#+,## . veiller à ce que l'ordre dans les listes soit toujours conservé ou au moins prise en compte de la contrainte "ordonné". - Optimisations et raffinements : . Chemin de préchargement des objets de transfert à l'intérieur des TopiaQuery . Les tables en bases doivent avoir les noms des interfaces pas des classes DO ... - Beaucoup plus tard : . Feuille de styles CSS sous la forme d'un nouveau layout java (benj) - Ancien : . prendre en compte le contenu de l'onglet doc des elements UML pour la generation des commentaires javadocs (classes, interfaces, package, attributs, operations) >> XSL et ObjectModel modifiés, la documentation est utilisée pour les classes, interfaces, operations et attributs dans la génération des interfaces sur les entités du modele. . tag-value transaction sur les operations des services avec les valeurs traditionnelles de la spec EJB (required, requiresNew, mandatory, supports, notSupported, never ). ex auto=required >> XSL et ObjectModel modifiés, valeur par défaut "supports". Pas utilisé encore, mais dès que l'on a la prise en compte des classes services . implanter les operations des entités si elles sont abstraites, on les genere abstraites dans les TO si elles ne sont pas abstraites en forward sur services dans les entités >> Fait pour les abstraites, en attentes de benj pour les forward . tag-value auto avec un pattern sur les attributs. ex auto=now >> XSL et ObjectModel modifiés. Le tag s'appelle "value" finalement. . tag-value mask avec un pattern sur les attributs. ex : mask=price puis dans les fichiers de traductions : price=#+,## >> XSL et ObjectModel modifiés. . tag-value enum avec un pattern sur les attributs. ex : 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 >> XSL et ObjectModel modifiés. Le tag s'appelle "enumName" finalement . tag-value i18n avec un pattern sur les attributs. ex : i18n=true >> XSL et ObjectModel modifiés. . classe d'association >> XSL et ObjectModel modifiés. . permettre le decoupage du modèle en plusieurs fichiers. Stéréotype <<extern>> sur les entités des autres modules qui se recréées dans un modèle donné pour y être utilisés. Ne sont pris en compte que les associations _entrantes_ sur ces classes externes. >> Fait . completer l'interface topiaEntity (getVersion, ...) >> Fait . dernier user ayant modifié une entité >> Fait . pouvoir monitorer un attribut (user, date, oldValue, new Value) Ces attributs ont une valeur tagguée versioned à vrai ou faux. -> getHistory[Attribut]():list<History> >> XSL et ObjectModel modifiés. -- Societe Code Lutin 2, rue Robert le Ricolais BP 20446 44304 NANTES CEDEX 3 Tel 02.40.50.29.28, Fax 02.40.93.99.21 http://www.codelutin.com --------------------------------

1 0

Documentation de Topia
by nicolas malin May 12, 2004

May 12, 2004

Voici certaines choses donc je pense la présence dans la documentation non négligeable pour la compréhension et l'utilisation de Topia. Installation et utilisation de maven Création des architectures de génération Déroulement théorique d'une génération Syntaxe du générateur Fichier de configuration pour le générateur Comment empecher la compilation des fichiers java générés Remettre en état un générateur bancale Voilà, ce sont mais proposition. Malin Nicolas

1 0

ajout d'un Tag
by olivier heintz May 11, 2004

May 11, 2004

Bonjour, est-il possible d'ajouter un tagvalue au niveau des class, attribue et autre nom du tag : gui valeur du tag : suite de chaine de caractère séparé par des virgules méthode pour y accéder : boolean isGui(String value); qui renvoi true si value est une des chaines contenu dans la valeur du tag Cela nous servirait pour la génération de la GUI -- Directeur de Projet Societe Nereide La collaboration et les bonnes pratiques en action bureau: +33 (0)2 4750 3054 mobile: +33 (0)6 3279 0323 http://www.nereide.biz

3 2

génération d'un fichier pour un package
by olivier heintz May 11, 2004

May 11, 2004

Y a t il un moyen simple de faire un générateur qui générerait un fichier pour toutes les entités d'un package?

2 1

Liste sur tous les Tagvalues utilisés
by olivier heintz May 8, 2004

May 8, 2004

Existe t-il une doc, quelque part qui indique quel sont les tags value qui sont lu et ce qu'ils renvoient. La question du moment c'est : comment je declare une propriété en tant que primaryKey Par avance Merci

1 1

TODO (v3) ToPIA et lutingenerator
by Cédric Pineau May 6, 2004

May 6, 2004

- Fait : . prendre en compte le contenu de l'onglet doc des elements UML pour la generation des commentaires javadocs (classes, interfaces, package, attributs, operations) >> XSL et ObjectModel modifiés, la documentation est utilisée pour les classes, interfaces, operations et attributs dans la génération des interfaces sur les entités du modele. . tag-value transaction sur les operations des services avec les valeurs traditionnelles de la spec EJB (required, requiresNew, mandatory, supports, notSupported, never ). ex auto=required >> XSL et ObjectModel modifiés, valeur par défaut "supports". Pas utilisé encore, mais dès que l'on a la prise en compte des classes services . implanter les operations des entités si elles sont abstraites, on les genere abstraites dans les TO si elles ne sont pas abstraites en forward sur services dans les entités >> Fait pour les abstraites, en attentes de benj pour les forward . tag-value auto avec un pattern sur les attributs. ex auto=now >> XSL et ObjectModel modifiés. Le tag s'appelle "value" finalement. . tag-value mask avec un pattern sur les attributs. ex : mask=price puis dans les fichiers de traductions : price=#+,## >> XSL et ObjectModel modifiés. . tag-value enum avec un pattern sur les attributs. ex : 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 >> XSL et ObjectModel modifiés. Le tag s'appelle "enumName" finalement . tag-value i18n avec un pattern sur les attributs. ex : i18n=true >> XSL et ObjectModel modifiés. . classe d'association >> XSL et ObjectModel modifiés. . permettre le decoupage du modèle en plusieurs fichiers. Stéréotype <<extern>> sur les entités des autres modules qui se recréées dans un modèle donné pour y être utilisés. Ne sont pris en compte que les associations _entrantes_ sur ces classes externes. >> Fait . completer l'interface topiaEntity (getVersion, ...) >> Fait . dernier user ayant modifié une entité >> Fait . pouvoir monitorer un attribut (user, date, oldValue, new Value) Ces attributs ont une valeur tagguée versioned à vrai ou faux. -> getHistory[Attribut]():list<History> >> XSL et ObjectModel modifiés. - A brève échéance : . modifier le ObjectModel pour avoir aussi séparement la description et le complément javadoc (en plus du getDocumentation() qui renvoie tout). Mettre une valeur de retour chaine vide par défaut pour ces trois accesseurs. . implanter les operations des entités pas abstraites en forward sur services dans les entités . tests unitaires . prendre en compte le tag-value i18n avec un pattern sur les attributs. ex : i18n=true . prendre en compte la tag-value enumName avec un pattern sur les attributs. ex : enumName=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 . Support des dates de validités sur les classes d'associations fromDate: Date, thruDate: Date -> isValidDate(date):true sur la classe d'association -> get[Attribute](date) sur l'entité qui l'utilise . prendre en compte la propriete "versioned" des attributs -> stocker l'historique des modifs (user, date, oldValue, new Value) : Une table historique par attribut, par entitée, globale ? Je pense par attribut. Benj un avis ? -> generer un getHistory[Attribut]():list<History> . pouvoir ajouter des champs à des entités. A discuter avec ben la meilleure facon de le faire. . Hook sur les services. A voir avec ben. . Interaction avec OfBiz. A voir avec ben. . mettre en marche le merdier. A faire avec ben. . tag-value value avec un pattern sur les attributs. ex value=now. Il faut maintenant le prendre en compte au moment de la création des TO. Benj comment vois tu la chose ? Comment est interprété le pattern ? - Ensuite : . faire en sorte d'utiliser la feuile xsl de lutingenerator pas celui des différents projets . permettre des classes entités abstraites . Implanter les TopiaQuery . Clone profond . toXML . Automatisation des xmlisation pour l'utilisation dans soot. . Internationnalisation des labels . Internationnalisation des attributs . Intégrer la generation sur des EJB faites par les stagiaires chinois . Generation des UI . prendre en compte le contenu de l'onglet doc des entités et attributs jusqu'au -- pour les tooltips . prendre en compte le mask avec un pattern sur les attributs. ex : mask=price puis dans les fichiers de traductions : price=#+,## . veiller à ce que l'ordre dans les listes soit toujours conservé ou au moins prise en compte de la contrainte "ordonné". - Optimisations et raffinements : . Chemin de préchargement des objets de transfert à l'intérieur des TopiaQuery . Les tables en bases doivent avoir les noms des interfaces pas des classes DO ... -- Societe Code Lutin 2, rue Robert le Ricolais BP 20446 44304 NANTES CEDEX 3 Tel 02.40.50.29.28, Fax 02.40.93.99.21 http://www.codelutin.com --------------------------------

1 0

TODO (v2) ToPIA et lutingenerator
by Cédric Pineau May 4, 2004

May 4, 2004

- A brève échéance : . tag-value transaction sur les operations des services avec les valeurs traditionnelles de la spec EJB (required, requiresNew, mandatory, supports, notSupported, never ). ex auto=required . prendre en compte le contenu de l'onglet doc des elements UML pour la generation des commentaires javadocs (classes, interfaces, package, attributs, operations) . veiller à ce que l'ordre dans les listes soit toujours conservé ou au moins prise en compte de la contrainte "ordonné". . implanter les operations des entités si elles sont abstraites, on les genere abstraites dans les TO si elles ne sont pas abstraites en forward sur services dans les entités . dernier user ayant modifié une entité . completer l'interface topiaEntity (getVersion, ...) . tests unitaires . mettre en marche le merdier . tag-value auto avec un pattern sur les attributs. ex auto=now . tag-value mask avec un pattern sur les attributs. ex : mask=price puis dans les fichiers de traductions : price=#+,## . tag-value enum avec un pattern sur les attributs. ex : 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 . tag-value i18n avec un pattern sur les attributs. ex : i18n=true . classe d'association . Support des dates de validités sur les classes d'associations fromDate: Date, throughDate: Date -> isValidDate(date):true sur la classe d'association -> get[Attribute](date) sur l'entité qui l'utilise . pouvoir monitorer un attribut (user, date, oldValue, new Value) Ces attributs ont une valeur tagguée versioned à vrai ou faux. -> getHistory[Attribut]():list<History> . pouvoir ajouter des champs à des entités. A discuter avec ben la meilleure facon de le faire. . permettre le decoupage du modèle en plusieurs fichiers. Stéréotype <<extern>> sur les entités des autres modules qui se recréées dans un modèle donné pour y être utilisés. Ne sont pris en compte que les associations _entrantes_ sur ces classes externes. . Hook sur les services. A voir avec ben. . Interaction avec OfBiz. A voir avec ben. - Ensuite : . faire en sorte d'utiliser la feuile xsl de lutingenerator pas celui des différents projets . permettre des classes entités abstraites . Implanter les TopiaQuery . Clone profond . toXML . Automatisation des xmlisation pour l'utilisation dans soot. . Internationnalisation des labels . Internationnalisation des attributs . Intégrer la generation sur des EJB faites par les stagiaires chinois . Generation des UI . prendre en compte le contenu de l'onglet doc des entités et attributs jusqu'au -- pour les tooltips - Optimisations et raffinements : . Chemin de préchargement des objets de transfert à l'intérieur des TopiaQuery . Les tables en bases doivent avoir les noms des interfaces pas des classes DO ... -- Societe Code Lutin 2, rue Robert le Ricolais BP 20446 44304 NANTES CEDEX 3 Tel 02.40.50.29.28, Fax 02.40.93.99.21 http://www.codelutin.com --------------------------------

1 0