Re: Templating for deferred binding / code generation

Finally I found the time to refactor the complete code generation process in Piriti from PrintWriter.write() to a Velocity based solution. The big advantage is that the generated code is much more readable. For more details please take a look at my blog post:

Re: Templating for deferred binding / code generation

Thanks for your input. I will give velocity templates a try and will let you know what I found out. - Harald -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To un

Re: Templating for deferred binding / code generation

I've never tried that but am very interested in how it works out for you if you ever decide to go this route. Please keep us posted! :) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolki

Re: Templating for deferred binding / code generation

My generators tend to be very heavily commented, and I try to keep blocks of printed code as small as possible in my code. I like to work up most of the boilerplate stuff in an existing abstract class or classes, and extend those when making my generated class. Small methods help too - your Elem

Templating for deferred binding / code generation

In my current project I'm using deferred binding to generate code. The code generation is heavily based on writer.write(String), writer.indent() and writer.outdent(): writer.write("%s = new %s<%s>();", var1, collectionImplementation, paramType ); writer.write("for (Element %s : %s) {", elementV