Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 171 posts at DZone. You can read more from them at their website. View Full User Profile

Next Up: Code Generation

  • submit to reddit

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.


Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


EG replied on Tue, 2008/10/07 - 3:21pm

I agree with your comments. You may want to take a look at the Jt Pattern Oriented Framework. It feature wizards or automated generation of J2EE applications.

Richard Kennard replied on Tue, 2008/10/07 - 6:17pm

May I humbly suggest Metawidget?

You say "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".

Metawidget says "Metawidget is a 'smart User Interface widget' that populates itself, at runtime, with UI components to match the properties of your business objects. Metawidget does this without introducing new technologies. It inspects your existing back-end architecture (such as JavaBeans, existing annotations, existing XML configuration files) and creates widgets native to your existing front-end framework (such as Swing, Java Server Faces, Struts, Android)".

Perhaps we are a good fit? I would be very grateful for your feedback.



P.S. Metawidget does not do static code generation, if that is something you really wanted. I discuss my reasons for that here.

Harald Krake replied on Wed, 2008/10/08 - 3:03am

You may also take a look at the Wurbelizer project. The generator part works pretty similar to JET or JSP-scriptlets but besides the code- and meta-level there is a third "source"-level, which corresponds to your regular, usually manually written sources. On this level you can bind generators (called "wurblets") with your sources. As a result, every existing source file may be turned into a template, where the generated code (according to some model) gets "mixed into". I've used this approach for many years now (not only for Java) and it works pretty well, especially for agile projects, where the model evolves in parallel with the sources.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.