Next Up: Code Generation

Ok, after looking at the JSF issues I‘ve been blogging about, and RF and some of the other things in the wind (the Spring meltdown), I have decided that the next step I want to take is in doing code generation. More tactical approach than the MDA based approaches. The stack itself (JSF/JPA/Hibernate/RichFaces) is great. But there is a hole between the component layer and the application layer. Lot of people see this as something that components can close. I don‘t see that. Yeah good components are great and we need more of them. But what I have seen on a lot of projects is that using TDD, the domain layer can stay pretty clean as the project grows. Where things get really bogged down is in mapping things to the ui, and controllers becoming fat and ugly, binding not being done right, domain anemia spreading as ui requirements are more fully realized, and no way to really make an assessment of what is still missing, so a LOT of time going into the last 20% on the ui tier.

The other reason code generation makes some sense is heuristics. If you have 3 wizards in your project and they all look like their own pile of code, implemented by different people, something is wrong. (This is, per CMM, a fundamental measure of maturity in my book, and longevity as the codebase grows.) I personally have never found that having one kind of controller class saves time. Furthermore, I have never seen any work done on the ui layer that is geared toward leveraging the power of the domain model. Now that we have annotations, we have enough information about the graph to do a lot of smart things, like generating controllers, facelets, etc.

The next question was what to use. I had looked at JET a bunch of times (part of eclipse). Went back and took another look. Liked what I saw. The good thing about such an approach is that I can see how I could do most of the work in code, and then change supported elements by just creating different templates to gen from. One of the reasons I‘m really fired up about this is that it is my general workflow to get the main entities mapped and then go create a basic ui. There are a TON of things we can make the generator do, using convention, for instance, mapping styles, doing edit/view variants, create wizards and edit mode interface elements, intelligently discover nested edit situations, etc. Then of course there is search: generate a simple search and a QBE-based search.

Having done a bunch of plugin development before, the other advantage JET has is that you can easily tie it to a plugin. My first goal is going to be to allow the user to right click on an entity and generate key ui elements (have a simple popup). Of course, the question that always comes up with code generation is what do you do when you make significant changes? The answer is that this should make it easier, frankly, if you do decide to do a real refactor. Inertia (as MS attests) is one of the greatest forces against progress. The ui definitely ends up being the source of a lot of inertia.

From http://www.jroller.com/robwilliams/