Hello Mark!
I think this is great! I suggest we create a project for the code generation
from template work once we have come so far. A project to contain the code
and any amount of default templates. Meanwhile create a wiki-page for these
requirements!
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.
- Re-generation, importing manual changes from previously generated files
or reverse engineering. Shall this be addressed? Do the template engines
mentioned address this?
/Linus
2011/8/31 Mark Fortner <[email protected]>
> I was thinking about Code Generation templates today when Michiel pointed
> out that the request for user-modifiable templates has been around for a
> while -- basically since 2000. I thought I would take a stab at defining
> some requirements for this and hopefully it would make it more tangible and
> perhaps generate some more thoughts on the subject.
>
> The primary goal of code generation templates is to provide users with a
> customizable means for generating code.
>
> The code generator should:
>
> - Allow users to use a default set of language-specific templates for
> generating code (which ship with ArgoUML).
> - Allow users to specify a common code header, without having to modify
> the templates themselves.
> - Allow users to clone the default argouml templates, to create their
> own customized versions of the templates.
> - Allow users to specify some common shared directory, or web server
> where code templates will reside.
> - Allow users to easily modify the templates through an editor (without
> having to leave ArgoUML to edit the template).
> - Allow users to generate Test Case stubs for classes.
> - Allow users to generate code for specific types
> - Support the generation of classes that use enums, annotations,
> generics.
> - Support the generation of projects which use specific directory
> structures. In Grails, for example, you want to be able to designate that
> classes with a <<Service>> stereotype are generated in the project/services
> directory; classes marked as <<Controllers>> should be generated in the
> project/controllers directory, etc
> - Support the use of Lists (not Vectors) as the default mechanism for
> aggregation. Perhaps this could be specified in the aggregation line
> itself
> between two classes.
> - Support the generation of javadoc comments when generating java code.
> This means support for @params, @author and other annotations in a comment
> block.
> - Minimize the amount of work required to support a new language.
> There should be a minimal number of templates that a user must modify in
> order to support a new language.
> - Allow users to generate code for the classes on a diagram, or in a
> package, in addition to generating classes for the entire project.
> - Provide progress feedback when generating the code.
> - Support a pluggable templating mechanism. If the user feels that
> they want to use Freemarker instead of Velocity, they should be able to
> plugin a new templating engine.
>
>
> Have I missed anything?
>
>
> Mark
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2833260
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]]
