Language Agnostic Templates (Reopened)

[MikeSchumacherCapgemini]

As a template developer, I want to be able to develop in the language the template results in, so that I can use features like code completion to easily figure out if the result actually works.

For much of the discussion so far, read the previously created issue #158

This is a workshop topic, any ideas are welcome and can be discussed in the comments

[hohwille]

I am happy to support this issue as I experienced that template development with freemarker templates is very tedious and error-prone.
IMHO implementing this idea of language-agnostic templates would massively boost productivity when using CobiGen as template developer.
I would be happy to implement a PoC and provide according PR.
To get started it would be awesome to have a small workshop to clarify the integration architecture:

• how could I implement my own template class? Would I need to extend https://github.com/devonfw/cobigen/blob/e79ace2758460a9d86ed9057b486dd7eca6b47ed/cobigen/cobigen-core/src/main/java/com/devonfw/cobigen/impl/config/entity/Template.java
• how could I override the default mechanism to find and load templates?
• how would I add some "plugin" or "module" that provides a new template-engine bundled with its own merger, its own template resolver?

[hohwille]

The Model of CobiGen is still just a Map?
https://github.com/devonfw/cobigen/blob/master/cobigen/cobigen-core-api/src/main/java/com/devonfw/cobigen/api/CobiGen.java#L81

Years ago I wanted to change this to a container class that wraps this class and can provide helper logic to resolve variables based on the model, etc.
Does that still make sense for the CobiGen Team?

[maybeec]

It has on the root been a map all the time but you can provide whatever you want from your reader. You can pass a key with beans as value and then navigate on the beans within your templates.

There is no valid way to consolidate a generic and proper bean model to represent open api files, pojos, XML models and so on in a generic way to be suitable every kind of template design

[hohwille]

All I am suggesting is to consider creating a wrapper class CobiGenModel that contains a Map<String, Object>.
Already with this you could add a lot of JavaDoc explaining what this is and how to use it.
There are many methods taking the model as Map<String, Object> and adding pages of JavaDoc to every @param there does not seem to be a good idea. Besides Map<String, Object> getMap() or Map<String, Object> asMap() the class CobiGenModel could step by step also be extended with useful helper methods to encapsulate logic on the model.

An additional option could even be to extend this CobiGenModel with sub-classes like CobiGenPojoModel or CobiGenOpenApiModel with advanced ways to access internal things easy. However, this is just a thought and not the suggestion.

[hohwille]

My minimal change for language-agnostic variable syntax at least made it into CobiGen for variables in paths:

cobigen/cobigen/cobigen-core/src/test/java/com/devonfw/cobigen/unittest/config/resolver/PathExpressionResolverTest.java

Line 142 in affa9cf

assertThat(target.evaluateExpressions("fooX__VariableName__Xbar")).isEqualTo("fooPrefixValueSuffixbar");

My own template engine could rely on the same and things would work consistently together what is nice so far.

[hohwille]

@MikeSchumacherCapgemini would you have time for a 2h break-out session in teams where we could do the scaffolding of a ultra-minimal PoC to setup such plugin providing its own template engine & template resolver?

To be minimal all templates could result in hard-coded hello world, etc.
I just need something to get started and can do the hard work for the complex internal things myself required for language-agnostic templates.

[hohwille]

Template-Engine itself seems rather straight-forward:
https://github.com/devonfw/cobigen/blob/master/cobigen-plugins/cobigen-templateengines/cobigen-tempeng-velocity/src/main/java/com/devonfw/cobigen/tempeng/velocity/VelocityTemplateEngine.java#L27

But how would I implement my own template-resolver and merger for java in the same plugin?

[hohwille]

It seems more complicated. CobiGen's design is giving me a writer per each call of a template instantiation. It further assumes that it has to write to temp and after successful generation do the merge.
All this does not fit with my vision.
I can follow this design for a PoC and ignore advanced merging, etc. to get started.
However, I assume on the long run I have plans that will go deeper into the core of CobiGen but lets be agile and see...