- 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 --------------------------------