> > Target languages and forms > I think adding target forms could be drastically more useful than just more languages. Adding more languages as you stated will be a lot of overhead and cause even more endless debates about language specific best practices and code style. However being able to represent your entire database in JSON is something I think could be very useful and language agnostic. This JSON could include all the raw table names as well as generated values like display names / class names.
Templating language > After working with both Slick code generation and JOOQ code generation I have been curious why no one has tried to use an HTML templating library. It is code that generates code dynamically and already has tons of useful built in features such as includes / partials / conditionals / loops. I would be interested to try and take a JSON representation of the database and run it through HTML templates and see how natural it feels. I think an added benefit would be the ability to add hooks into the code generation wherever you wanted by just modifying / customizing a few html templates. Style > Its generated code if I can read it without too much effort I don't care what it looks like. The apis should be fairly self explanatory so you shouldn't need to be digging into the generated code all that frequently. I personally have all of my generated code pushed to a src/generated/java directory so its explicitly clear you should never touch any code in that directory. > Generator strategies I have found JOOQs current offerings plenty sufficient so far but it never hurts to have additional pluggabe strategies. Disambiguation / compiler "optimisations" > This is fairly critical also keep in mind this can get more and more complex if you decide to support more languages. Custom code > I have had a pretty good experience customizing the JOOQ DAO generators on my own. I was able to auto generate some additional queries that I would use frequently. Getting the code in the right places was sometimes difficult. I felt somewhat limited by the hooks to add custom code. At the same time I don't think adding additional hooks is the right solution. You could end up with tons of before / after hooks for every section of code and that could get out of hand quickly. I like the idea of a simplistic plugin system to allow users to pick / choose features and customize at will. That could also be quite complicated to write / test / maintain with tons of possible combinations. Maybe have a JOOQ standard that is well maintained and the ability for contributors to maintain their own plugins for anyone who is not happy with your approach? It might be interesting to pick a subset of all the features you want and we can throw together some proof of concepts to see what works well and how they compare. Bill On Tuesday, December 29, 2015 at 6:27:46 AM UTC-5, Lukas Eder wrote: > > Dear group, > > The jOOQ code generator is one of the biggest assets when using jOOQ. It > allows for referring to your schema in a type safe way, allowing to > leverage IDE auto completion with tables, columns, procedures, etc. > > However, it has grown organically and it thus doesn't allow for the > extensibility that some of you would like. It is time to start thinking > about the future of jOOQ-codegen and jOOQ-meta, to collect ideas for jOOQ > 4.0 in that area, or perhaps even for prior releases. *So, this is a good > time to chime in and discuss potential requirements.* > > The relevant issue is: > https://github.com/jOOQ/jOOQ/issues/3883 > > These are, roughly, the existing features, or existing feature requests: > > *1. Target languages and forms* > > jOOQ currently supports Java and Scala - the most popular languages on the > JVM. Does it make sense to support other languages? Or perhaps even data > formats, like XML? > > This is an interesting topic, but it is also very demanding in terms of > complexity budget. Alternative languages cannot be integration tested as > well as Java without adding substantial effort. > > *2. Templating language* > > The code generator currently uses a home-grown templating "language" via a > home-grown, internal, undocumented API. > > In the past, users have suggested using Xtend ( > http://www.eclipse.org/xtend) instead. The advantage of Xtend is that the > template language is built into the Xtend language, and it feels extremely > natural. > > At the time, the idea of integrating Xtend was rejected, because the Xtend > tooling was very Eclipse dependent. This is no longer true, and Xtend is > still a very interesting consideration. > > Alternatively, a programmatic language model (like XJC has) could be > interesting, although it would be very limiting in terms of what's possible > in 1. Target languages. > > *3. Style* > > Programmers like endless discussions about curly braces, indentations, > tabs and spaces. jOOQ currently doesn't embrace this sort of "creativity" > :-) > > It would be great if the generated code style could be influenced in one > way or another, although, this is a rather low priority. > > *4. Generator strategies* > > Most customisation is about naming style. Do you want your database > objects in PascalCase? camelCase? UPPER_CASE? lower_case? > > Is this feature sufficient? What's missing here? > > *5. Disambiguation / compiler "optimisations"* > > jOOQ code compiles almost always. We've thought of many edge-cases where > generated code might cause conflict, e.g. because of naming ambiguity, > invalid identifiers, etc. This is a must-have in any future implementation. > > *6. Custom code* > > Currently, there are a few ad-hoc means of introducing custom code into > generated artefacts. This is mostly done via method extension, which is > rather limiting. > > Recently, there has been quite a bit of criticism about the generated > DAOs, and the fact that they're not really useful for use with Spring or > CDI. That's true, but we don't want to patch them little by little, adding > not well thought through features at this point. > > Instead, YOU should be able to generate DAOs (or repositories, or > services, or session beans) very easily yourself, using jOOQ-meta and a > better jOOQ-codegen. YOU should then be able to publish your jOOQ code > generation "plugins" for reuse in the community. > > Other use-cases are: > > 5.1. Support for additional validation annotations > 5.2. Support for additional Spring or Java EE annotations > 5.3. Support for JPA annotations > 5.4. Support for fluent setters > 5.5. Support for alternative object types (e.g. repositories, services, > etc.) > 5.6. Mutable / immutable POJOs. > 5.7. "Views" expressed in jOOQ (i.e. SQL strings that should generate as > org.jooq.Table) > > In fact, I believe that the core code generation functionality should be > built upon such a plugin system, rather than providing tons of flags to > turn on/off individual features > > *Be a part of it* > > I'm looking forward very much to your feedback, and enthusiast discussion! > > Lukas > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
