You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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:
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.
The text was updated successfully, but these errors were encountered: