Jupp I did create a (very) simple interface to encapsulate all calls to the 
template engine, it consist of the methods:
        /**
         * Initializes the template engine.
         * 
         * @param dir
         *            The directory that contains the templates.
         */
        public void init(File dir);

        /**
         * Generates content using a template and writes it to a file.
         * 
         * @param templateName The name of the template to be used.
         * @param destFile The destination file.
         */
        public void generate(String templateName, File destFile);

        /**
         * Gets an object from the template engine context.
         * 
         * @param key
         *            The key for which the object is stored.
         * @return The found object.
         */
        public Object get(String key);

        /**
         * Puts an object to the template engine context.
         * 
         * @param key
         *            The key for which the object is to be stored.
         * @param value
         *            The object to be stored.
         */
        public void put(String key, Object value);

Needs to deal with more than one context and maybe no File type for parameters, 
but it does the job (i.e. is useful for the requirements I had).

Thomas


-------- Original-Nachricht --------
> Datum: Thu, 1 Sep 2011 10:09:16 -0700
> Von: Mark Fortner <[email protected]>
> An: [email protected]
> Betreff: Re: [argouml-dev] Templated Code Generation

> Hi Thomas,
> I don't mind contributing some time to it.  I used Velocity as one of the
> templating engines in ArgoPrint, and am pretty familiar with it.  Since
> Velocity is used in couple of places in ArgoUML, it might be good to stick
> with it for the initial implementation, but make sure we have enough
> interfaces in place that it's easy enough to plugin a different templating
> engine.
> 
> Mark
> 
> On Thu, Sep 1, 2011 at 10:00 AM, Thomas Neustupny <[email protected]> wrote:
> 
> > Hi Mark et al,
> >
> > thank you for approaching the topic from the requirements side, this is
> > needed to engineer poweful features for ArgoUML! I have not much time in
> the
> > next weeks, but I can contribute with some hints on the (opposite?)
> > technical side: we have worked with Velocity already. This template
> engine
> > is also used by AndroMDA. Since we use Antlr, we are also aware of
> > StringTemplate, another template engine. But with velocity, I know of at
> > least two working examples that generate Java code from templates+model,
> > both of them as ArgoUML modules:
> >
> > * http://argouml-modulegenerator.tigris.org/ (my baby)
> > * a template base Java generator by Andreas Rückert (I have the
> sources,
> > but will not give them away without talking to him)
> >
> > Maybe it's too early to talk about the concrete libs to use, but I just
> > wanted to let you know that there's some experience. Just go aheas with
> the
> > concept!
> >
> > (OK, I'm a little bit worried who will later implement it, do you think
> > someone will volunteer?)
> >
> > Regards,
> > Thomas
> >
> > -------- Original-Nachricht --------
> > > Datum: Thu, 1 Sep 2011 07:49:50 -0700
> > > Von: Mark Fortner <[email protected]>
> > > An: [email protected]
> > > Betreff: Re: [argouml-dev] Templated Code Generation
> >
> > > Hi Linus,
> > > It should be pretty easy to have template-specific file naming
> patterns.
> > >  I've started creating a model based on our discussions and I'll see
> if I
> > > can load that onto the wiki this weekend.
> > >
> > > Mark
> > >
> > >
> > > On Thu, Sep 1, 2011 at 7:43 AM, Linus Tolke Tigris <[email protected]>
> > > wrote:
> > >
> > > > *Hello Mark!
> > > > *
> > > > *
> > > > *
> > > > *In my current project we have the header files and c++ files in the
> > > same
> > > > directory. In other projects I have seen them in two different
> > > directories.
> > > > *
> > > > *
> > > > *
> > > > *         /Linus*
> > > >
> > > >
> > > > Den onsdagen den 31:e augusti 2011 skrev Mark Fortner:
> > > >
> > > > Hi Linus,
> > > >> In ArgoPrint I have a TemplateMetaFile object which contains things
> > > like a
> > > >> file naming template.  We could use a similar approach for code
> > > generation
> > > >> templates.
> > > >>
> > > >> It's been a while since I've written any C++.  If you're generating
> > > code
> > > >> do you typically put the headers in one directory and the
> > > implementations in
> > > >> another directory?  Perhaps splitting things up into an API and an
> SPI
> > > >> directory?
> > > >>
> > > >> Mark
> > > >>
> > > >>
> > > >> On Wed, Aug 31, 2011 at 11:03 AM, Linus Tolke Tigris
> > > <[email protected]>wrote:
> > > >>
> > > >>> Great Mark!
> > > >>>
> > > >>> For filenames, I am also thinking C++ where each class has a .h
> file
> > > and
> > > >>> a .cpp file i.e. two separate templates or a single template that
> > > generates
> > > >>> two files. I want to see this to be determined among the set of
> > > templates. I
> > > >>> assume this is easily fixed.
> > > >>>
> > > >>> I agree that it is best to put reverse engineering aside. It is
> great
> > > >>> that we state this up front. It simplifies things a lot.
> > > >>>
> > > >>>         /Linus
> > > >>>
> > > >>>
> > > >>> 2011/8/31 Mark Fortner <[email protected]>
> > > >>>
> > > >>>>
> > > >>>> Hi Linus,
> > > >>>> I'll definitely move the results of the discussion into a wiki
> page.
> > > >>>>
> > > >>>>
> > > >>>>> I miss two things but it might be my lack of knowledge of what
> is
> > > >>>>> included in the template engines.
> > > >>>>>
> > > >>>>>    - In the template it shall be able to express filename or
> > > filenames
> > > >>>>>    to be used.
> > > >>>>>
> > > >>>>> I don't know if the template itself should know about the
> filename,
> > > but
> > > >>>> you can definitely pass a file name to the templating engine. 
> There
> > > are two
> > > >>>> use cases here:
> > > >>>>
> > > >>>>
> > > >>>>    - *Straight template-based generation*: you have a class, and
> an
> > > >>>>    output directory, and a template -- the template engine uses
> this
> > > data to
> > > >>>>    determine where what to write and where to write it. 
> Determining
> > > the output
> > > >>>>    directory and classname is rather straight-forward:
> > > >>>>
> > > "${outputdir}/${packageName.toPath()}/${className}.${fileExtension}"
> > > >>>>    - *Project-based generation*: you have a domain class, a
> project
> > > >>>>    directory, and a template -- the correct directory is
> determined
> > > based on
> > > >>>>    the fact that it's a domain class, it's a Grails project (or
> some
> > > other
> > > >>>>    framework), and we know what the project root directory is.
> > > Something like
> > > >>>>
> > >
> >
> "${projectRoot}/grails-app/domain/${packageName.toPath()}/${className}.groovy"
> > > >>>>
> > > >>>>
> > > >>>>>    - Re-generation, importing manual changes from previously
> > > generated
> > > >>>>>    files or reverse engineering. Shall this be addressed? Do the
> > > template
> > > >>>>>    engines mentioned address this?
> > > >>>>>
> > > >>>>> In my mental model, language support = reverse engineering +
> code
> > > >>>> generation, and for the time being, I'd be satisified if we just
> had
> > > >>>> modifiable templates for code generation.  I'm not completely
> > > dissatisfied
> > > >>>> with reveng at the moment, there are just a few bits that are
> need
> > to
> > > be
> > > >>>> updated to properly support some features in the java language.
> So
> > > I'd
> > > >>>> rather put reveng to the side for the time being and focus on
> code
> > > >>>> generation. My personal feeling is that projects that are small
> and
> > > >>>> well-defined are more likely to be worked on by volunteers with
> > > limited
> > > >>>> available time and we should probably try to keep this as minimal
> as
> > > >>>> possible.
> > > >>>>
> > > >>>> Mark
> > > >>>>
> > > >>>
> > > >>>
> > > >>
> > >
> > > ------------------------------------------------------
> > >
> >
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2833966
> > >
> > > To unsubscribe from this discussion, e-mail:
> > > [[email protected]].
> > > To be allowed to post to the list contact the mailing list moderator,
> > > email: [[email protected]]
> >
> > --
> > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> >
> > ------------------------------------------------------
> >
> >
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2833991
> >
> > To unsubscribe from this discussion, e-mail: [
> > [email protected]].
> > To be allowed to post to the list contact the mailing list moderator,
> > email: [[email protected]]
> >
> 
> ------------------------------------------------------
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2833993
> 
> To unsubscribe from this discussion, e-mail:
> [[email protected]].
> To be allowed to post to the list contact the mailing list moderator,
> email: [[email protected]]

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2833994

To unsubscribe from this discussion, e-mail: 
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email: 
[[email protected]]

Reply via email to