Any potential in using Xtend for templating?

lukaseder commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

verhas commented 11 years ago

What is the business value of this feature?

lukaseder commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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.

verhas / fluflu

Any potential in using Xtend for templating? #4