Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CR: Manage imports as side-effect #252

Open
hohwille opened this issue Sep 9, 2016 · 2 comments
Open

CR: Manage imports as side-effect #252

hohwille opened this issue Sep 9, 2016 · 2 comments

Comments

@hohwille
Copy link
Member

hohwille commented Sep 9, 2016

Currently CobiGen is using Freemarker as template engine. Like most generic template engines it is reading a template and processing this in a sequential way copying the input to the generated output whilst doing some transformations triggered by the engine programming language (variables, macros, etc.).

On the other hand we want to write templates in an efficient way. Now I am facing a big conflict here. With the linear processing approach it is very hard to generate the dynamic import statements. In the end you have to duplicate all loops, conditions, caluclations, etc. once in the import statements block and once in the body.

Actually what we really need is a templating engine that allows to produce things like an import as a side effect while generating the body. As CobiGen aims to be language agnostic it is tough to find a perfect design for this. However, I could imagine of the following approach:

Depending on the output format (via file extension of template/output file) we detect the language. The responsible language plugin defines the sections of the output file with something like an import section for Java, C#, TS, etc. while such thing does not exist for e.g. XML or properties. Now in a template we could introduce a syntax to generate to a different section than the current one. To avoid knowledge about import statements a generic approach would be something like:

<#section import>
import ${property.type.qualifiedName};
</#section>

If so you could even imagine about a fully language agnostic approach by also surrounding the toplevel imports with the section and make the first declaration of a section the place where its content has to appear in the final output (or add another attribute or tag for section like section-def).

An alternative would be to add knowledge about imports and just add some function to register an import:

<#import ${property.type.qualifiedName}>

Anyhow, the underlying template engine has to be designed in a way that it has buffers for named sections and only writes to the final output after generation of the file is completed.

@hohwille
Copy link
Member Author

hohwille commented Sep 9, 2016

FYI: That is the same reason why eclipse supports this in code templates:
https://www.yammer.com/capgemini.com/#/Threads/show?threadId=746301355

@github-actions
Copy link

Stale topic. Please negotiate closing or discussing the relevance of this ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants