Any potential in using Xtend for templating?

[lukaseder]

I've made great experiences with Xtend as a templating engine for generating code: http://www.eclipse.org/xtend/

I'm using it to generate all the row value expression related stuff in jOOQ, where similar code has to be duplicated, such as Record1, Record2, Record3, etc...

Do you see any potential in using it for fluflu?

[verhas]

Do you suggest to use

• a template engine provided with Xtend
• write part of fluflu using Xtend, or
• create the generated code as an Xtend code?

[lukaseder]

The first. As a matter of fact, there doesn't need to be formal Xtend support in fluflu. It would be sufficient if a templating SPI was exposed, which can be implemented either using your current string-based templates, or in any other way (e.g. by using Xtend).

The SPI might look like this:

public interface Templates {
    String endMethod();
    String fluentClassHeader();
    String fluentMethod();
    String method();
    String startMethod();
    String stateClassHeader();
}

[verhas]

May I rephrase the suggested feature as the following:

Provide an SPI so that some external party can plug-in some templating functionality into fluflu. The external templating can be written in Xtend or in just any other language that can implement an interface and can be configured so that fluflu may use that engine instead of the build-in string based templates.

Question:

How should the configuration be done. There are ideas (brainstorming, even weird ones, just came up in my mind):

• Use standard Java ServiceLoader (what if there are more than one implementations available)
• Read configuration from a text file (where should the text file be, how can the processor find the location)
• Configure the templating in an annotation (weird)

[lukaseder]

I had also thought of the ServiceLoader. I guess, at such a low level (APT), this might seem appropriate.

[verhas]

What is the business value of this feature?

[lukaseder]

That should be pretty obvious. A versatile code generator is always better than a rigid one. XJC may be poorly documented, but it's very powerful in its extensibility.

Obviously, this isn't a high-prio task, but a long-term strategy (maybe)

[verhas]

A versatile code generator is always better than a rigid one.

Not true. A versatile code is more complex, more error prone and higher cost to maintain. Generally the cost is higher. If there is no gain on the other side of the balance then the cheaper, simple code is better.

[lukaseder]

You're probably speaking from bad experience :-) A well-defined SPI doesn't necessarily introduce complexity, it may even reduce it by externalising complex solutions to SPI implementations.

I'll leave this up to you. If fluflu will ever have a broader audience, I'm sure this will be asked time and again... Feel free to close this issue, if you don't agree.