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