Romain Manni-Bucau a écrit :
l'idée de parcourir plusieurs fois le modèle ne me plait pas mais il me semble indispensable.
Bonjour, Désolé pour ma réponse tardive. En fait ce qu'on fait généralement c'est préparer les données avant de générer. D'expérience ca permet de rendre le template (générateur) plus lisible. Car nous nous sommes rendu compte que parcourir plusieurs fois le modèle n'a que peu d'impact (les perfs ne s'en ressentent pas) par rapport à un template qui devient illisible (c'est souvent le cas). Cordialement, Arnaud.
merci de vos réponses
Le jeudi 13 août 2009 à 15:51 +0200, Eric Chatellier a écrit :
Romain Manni-Bucau a écrit :
Ce que j'aurais voulu était de garder le concept d'écriture des templates entre /*{ }*/ mais que ceux-ci puisse apartenir à un groupe un groupe étant écrit d'un bloc.
Par exemple /*[1]{toto1}*/ /*{pas de groupe 1*}/ /*[2]{toto2}*/ /*{pas de groupe 2*}/ /*[1]{toto3}*/
écrirait : toto1 toto3 /*{pas de groupe 1*}/ toto2 /*{pas de groupe 2*}/
Ajouter un "signet" crée un nouveau buffer à l'endroit où on est, ne pas signaler de signet crée un nouveau buffer à la fin.
Pour prendre un exemple plus parlant peut-être, si je veux générée un .java, je crée par exemple un signet "imports", un signet "attributes", et un dernier "methods" et je peux par exemple faire :
/*{ package .... }*/ createPoint("imports"); /*{ public class .... }*/ createPoint(attributes); createPoint(method); /*[methods]*{ public void useless() {} }*/ /*[imports]{ import java.util.*; }*/ /*[attributes]{ private int toto = 0; }*/ /*{ } }*/
qui me donne : package ... import java.util.*; public class ... private int toto = 0; public void useless() {}
Je comprend bien, mais on ne peut pas faire ça. Et je trouve que ça rend le template plus difficile à lire.
Dans l'idée (disons son interface) cette classe conviendrait mais on perd le côté template inclut dans le code qui était appréciable :
Oui, c'est une autre façon de générer sans template finalement.
Mais je ne vois pas très bien l'intérêt de passer par des "signet" pour générer ce genre de code, si ce n'est parcourir une seule fois le modèle.
Dans votre cas, vous voulez générer "import", "attributs", "méthodes". On a exactement les mêmes problématiques de notre coté. Donc fait ça simplement, même si ce n'est pas optimisé en temps : - parcourt du modèle pour génération des imports - parcourt du modèle pour génération des attributs - parcourt du modèle pour génération des méthodes
Il y a même une générateur d'import qui a été développé récemment : http://www.nuiton.org/repositories/entry/eugene/trunk/eugene/src/main/java/o...
Bref, je ne peux pas vous aider plus je pense, apart vous montrer des exemples de générateurs : http://www.nuiton.org/repositories/browse/eugengo/trunk/src/main/java/org/nu... http://www.nuiton.org/repositories/browse/topia/trunk/topia-persistence/src/...
_______________________________________________ Eugene-devel mailing list Eugene-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/eugene-devel
-- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28