Author: bpoussin Date: 2009-08-21 15:23:16 +0200 (Fri, 21 Aug 2009) New Revision: 606 Modified: trunk/eugene/src/main/java/org/nuiton/eugene/ImportsManager.java trunk/eugene/src/main/java/org/nuiton/eugene/models/object/xml/ObjectModelImpl.java trunk/eugene/src/site/rst/DiscussionSurTypeDeGeneration.rst trunk/eugene/src/site/rst/ObjectModel.rst trunk/eugene/src/site/rst/Todo.rst Log: - if fqn have no package, don't use it in import - small correction in documentation - add task in todo (generation by model creation) Modified: trunk/eugene/src/main/java/org/nuiton/eugene/ImportsManager.java =================================================================== --- trunk/eugene/src/main/java/org/nuiton/eugene/ImportsManager.java 2009-08-21 07:43:54 UTC (rev 605) +++ trunk/eugene/src/main/java/org/nuiton/eugene/ImportsManager.java 2009-08-21 13:23:16 UTC (rev 606) @@ -67,6 +67,11 @@ * @return true if import add was successful */ public boolean addImport(String fqn) { + // if no package don't include it + if (fqn.indexOf(".") == -1) { + return true; + } + // Exclude java.lang classes if (fqn == null || "".equals(fqn.trim())|| (fqn.startsWith("java.lang.") && fqn.lastIndexOf(".") == 9)) { Modified: trunk/eugene/src/main/java/org/nuiton/eugene/models/object/xml/ObjectModelImpl.java =================================================================== --- trunk/eugene/src/main/java/org/nuiton/eugene/models/object/xml/ObjectModelImpl.java 2009-08-21 07:43:54 UTC (rev 605) +++ trunk/eugene/src/main/java/org/nuiton/eugene/models/object/xml/ObjectModelImpl.java 2009-08-21 13:23:16 UTC (rev 606) @@ -191,14 +191,19 @@ if (qualifiedClassName == null) { return null; } - if (!hasClass(qualifiedClassName) && log.isWarnEnabled()) { - log.warn("Class " + qualifiedClassName + " not found in model"); - log.warn("You may forgot to declare for good an external class ?"); + if (!hasClass(qualifiedClassName)) { //FIXME Decide if this is a good idea - log.warn("Generating fake class"); + if (log.isWarnEnabled()) { + log.warn("Class " + qualifiedClassName + " not found in model"); + log.warn("You may forgot to declare for good an external class ?"); + + log.warn("Generating fake class"); + } ObjectModelClassImpl result = new ObjectModelClassImpl(); int index = qualifiedClassName.lastIndexOf("."); - result.setPackage(qualifiedClassName.substring(0, index)); + if (index != -1) { + result.setPackage(qualifiedClassName.substring(0, index)); + } result.setName(qualifiedClassName.substring(index + 1)); result.postInit(); return result; Modified: trunk/eugene/src/site/rst/DiscussionSurTypeDeGeneration.rst =================================================================== --- trunk/eugene/src/site/rst/DiscussionSurTypeDeGeneration.rst 2009-08-21 07:43:54 UTC (rev 605) +++ trunk/eugene/src/site/rst/DiscussionSurTypeDeGeneration.rst 2009-08-21 13:23:16 UTC (rev 606) @@ -19,14 +19,14 @@ l'inverse n'est pas vrai. Car la seconde catégorie demande des générateurs beaucoup plus simple, ce qui est d'ailleur un avantage pour la maintenance. -Code Lutin utilise un générateur du deuxième type: LutinGénérator +Code Lutin utilise un générateur du deuxième type: Eugene Quelques générateurs de la première catégorie: - Acceleo (Obeo) - Pragmatic (Argia) Les principes de Eugene -=============================== +======================= - le générateur ne doit jamais modifier les fichiers de l'utilisateur. - l'utilisateur ne doit jamais modifier le code généré - le modèle est toujours la source (pas de reverse, pas de modification du Modified: trunk/eugene/src/site/rst/ObjectModel.rst =================================================================== --- trunk/eugene/src/site/rst/ObjectModel.rst 2009-08-21 07:43:54 UTC (rev 605) +++ trunk/eugene/src/site/rst/ObjectModel.rst 2009-08-21 13:23:16 UTC (rev 606) @@ -62,7 +62,7 @@ Une fois le XMI ramené à un XML compréhensible, le modèle est chargé en mémoire afin de subir la génération. -Ainsi, le modèle instancé est basé sur le diagramme de classes suivant : +Ainsi, le modèle instancié est basé sur le diagramme de classes suivant : .. image:: images/ObjectModel.png Modified: trunk/eugene/src/site/rst/Todo.rst =================================================================== --- trunk/eugene/src/site/rst/Todo.rst 2009-08-21 07:43:54 UTC (rev 605) +++ trunk/eugene/src/site/rst/Todo.rst 2009-08-21 13:23:16 UTC (rev 606) @@ -15,3 +15,90 @@ - peut-etre faire des tests unitaires avec http://juxy.tigris.org/ pour le xls +- Permettre de faire du 'model to model' avant la generation + +Model to Model +============== + +Pour tout ce qui est génération de classe Java, le principe de base d'Eugene +est de dire que le développeur écrit directement ce qu'il souhaite voir dans +le fichier final. + +Cela pose quelques difficultés: + +- difficulté de prévoir les imports +- difficulté d'éviter la génération de deux méthodes ayant le même nom + +L'idée serait alors de constuire la classe Java souhaitée au final en appelant +des méthodes (addImport, addMethod, addAttribute, ...). Ceci nous donnerait +alors un nouveau modèle mémoire dont on demanderait la génération à un +générateur sans inteligence qui se contenterait d'écrire le code Java modélisé. + +L'avantage est que pour chaque méthode à ajouter on peut demander avant si elle +n'a pas déjà été ajoutée et ainsi potentiellement la renomé avant de l'inclure. +D'ajouter de façon automatique tous les imports des arguments des méthodes, ... + +Pour pouvoir faire cela, nous pourrions nous baser sur ObjectModel, mais des +ajouter doivent être fait: + +- pouvoir indiquer sur une Class une série d'import. +- pouvoir ajouter un message de licence +- pouvoir ajouter sur une méthode sont code source + +Ce dernier élément est le plus problèmatique, car il deviendrait pénible de +devoir instancier tout le code de la méthode en objet et on perdrait l'idée +de départ d'Eugene. + +Dans eugène il est déjà possible de modifier la transformation des tags de +génération '/\*{' et '}\*/' qui par défaut génère un 'ouput.write("...");' +Dans notre cas, il faudrait quelque chose comme 'method.addCode("...");' ou +encore plus simplement '"..." +' ce qui pourrait donner:: + + addImport(MonObject.class); + method.addCode( + /*{ int i = 0; + i = 1+2; + MonObject result = new MonObject(result); + return result; + }*/ + ); + +qui deviendrait:: + + addImport(MonObject.class); + method.addCode( + "int i = 0;\n" + + "i = 1+2;\n" + + "MonObject result = new MonObject(result);\n" + + "return result;\n" + ); + +On garde la facilte d'écriture du code à générer et on permet d'ajouter +facilement des imports dont on aurait besoin dans le coprs de la méthode. Aucun +traitement complexe du code de la méthode n'est donc nécessaire. + +Ce nouveau mode de génération ne serait qu'une moyen complémentaire de la +génération actuelle. + +Travail a faire: + +- ajout d'objet dans ObjectModel +- ajout de méthode de modification dans ObjectModel +- création d'un template de génération d'un POJO (génération direct d'un modèle) + +Il serait toute fois dommage d'ajouter tout un ensemnble de setter sur les +interfaces d'ObjectModel qui le rendrait moins clair pour les générateurs. +Il faut donc trouver une solution pour permettre l'instanciation et la +modification de classe implantant l'ObjectModel sans pour autant les ajouter +au interface. + +Une idée pourrait-être l'utilisation de Helper qui permette de créer et modifier +le modèle:: + + ObjectModelClass clazz = ObjectModelHelper.createClass(); + ObjectModelOperation method = ObjectModelHelper.addMethod( + clazz, "name", "typeRetour", "paramName", "typeParam"); + ObjectModelHelper.addImport("java.util.List"); + ObjectModelHelper.addCode(method, + /*{ blablabla + }*/