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=2833380
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]]
