I'm getting ready to announce the project on a few mailing lists, so in preparation, I'm going to attempt to explain the idea again. Please bear with me...
Groovy, Grails, Rails, recent interviews and feeling a little like Old Gill...
I love Java. I've loved Java for a long time. I started coding Java in college, when it was version 1.0. Try this out. Its an asteroids clone I wrote. If you can dig up a Pentium 75, it will actually work.
For the past several years I've been running a small technology group building fairly heavyweight enterprise applications for a financial company. A relatively sheltered existence, to be sure. They move very slow on to new technologies. For my own part, I read a lot, but I'll admit I stuck pretty much to the Java realm. Maven, Hibernate, JSF? All over it. Ruby and Rails? Didn't even look.
So, I've been interviewing lately. It turns out that not everybody thinks Rails is mostly hype (as I did). Specifically, I spent a day at a company called Cyrus Innovation (cyrusinnovation.com). Its a small group of very intelligent people who actually believe in agile techniques, pair programming, do a lot of Java, and absolutely get into Ruby and Rails.
At 31, my interviewing experience left me feeling a little like Old Gill (simpsons reference). The prevailing attitude, at least in some areas, is that Java is old and Rails is the next big thing. That would be fine, except I really can't fathom tossing away such huge piles of quality, tested code that exist in the Java space. Also, Java is a great language for certain classes of applications. Part of the value of Rails comes from the language dynamics of Ruby, but a lot of the advertised productivity improvement comes simply from the framework. In short, there's no magic going on. Good ideas, but ideas are transferable.
It didn't take long to stumble onto Groovy and Grails. Its like an intellectual slap in the face for a long time Java programmer. Groovy is a dynamic language, syntactically similar to Java, which can seamlessly inter-operate with Java. Grails is a Rails-like framework built on top of Groovy. Assuming some time for stabilization and optimization, it levels the playing field in my mind. You can use the platform you're currently on, and extend it with a significantly more expressive language where needed. Not throwing the baby out with the bathwater.
Groovy and Grails are behind in terms of IDE support and general "smoothness" of development. I personally think Groovy is a fantastic technology, and my biggest concern is it simply won't get the time and effort needed to make it a first class option for the Java platform. It should, though. Java and Groovy together is a fantastic combination.
Right before I started with the dynamic languages, I had first tried out Wicket. For the past year or so I've been working with JSF. First on my own, then with my soon to be released major project. JSF is more productive than simpler options like Struts, and has some major industry support, but many things with JSF feel unnatural.
I had read about Wicket here and there, but had mentally stuffed it into the, "Oh man, another web framework" category (ie. the circular file). I finally gave it a shot, though. Yep, I was totally wrong. Wicket does some things in a way that seems, in retrospect, obvious. I think it has the freedom of not trying to be everything to everybody, and not having large committees making decisions, as JSF has to deal with. Its a great technology for the 98% of web applications that aren't be hit by thousands of users concurrently. Its a component framework, like JSF, which is nice for creating more complex user input constructs. Its page creation and linking features, however, are much better than Struts and JSF. By "much better", I mean respectively: Struts, JSF, Wicket -> walking, skateboard, ferrari. The way models can detach and reattach data objects is just awesome. I'll stop there. In summary, I like it.
So, now I'm all big on Groovy. What I disliked about Rails, and what I like about Groovy and Grails, is that you can use Java's existing code base in your new apps. Along with that, as Wicket really is great technology, I want to use it from Groovy code. Can you use Wicket and Groovy together? Yes, but its clunky. Why? Well, if you compile your Groovy into classes, it'll just work. That's good. However, Wicket relies on anonymous inner classes all over the place. You can create regular classes and override methods in them, but anonymous inner classes make that process much easier. Works great in Java. Groovy, however, doesn't do anonymous inner classes. Groovy uses closures, which are sweet as well, but you can't use closures with Wicket (obviously. If that wasn't obvious, you should probably stop now because you're going to be really lost soon). My goal with this project is to make Wicket programming with Groovy at least as easy as it is with Java, and hopefully easier. Besides, of course, the inherent expressiveness of the language itself.
Wicket Groovy Builder
Groovy has a concept called a builder. See here...
The idea came to me to use a builder when I saw the SwingBuilder. It allows you to build a Swing app in groovy, with significantly simpler code. The Swing component structure is roughly tree shaped. Well, that's the first thing I noticed about Wicket code. It looked a lot like Swing code.
Simple concept. Write a builder implementation that build a Wicket component tree. Sounds easy, but its fairly complex. I won't go in to it, but lets say I do some things with closures that they weren't meant to do. Over the next couple weeks I'm going to be working on the project as well as the documentation, so hopefully I'll have some more detail on the implementation soon.
Originally I started doing this as a seperate project, but Eelco Hillenius from wicketstuff contacted me about the project. He had done some work on the 'wicket-groovy' project from wicketstuff, and proposed I move the builder code in there. Here's the website...
Right now my code is in the 1.3 branch only. You can see the latest subversion tree at...
Does it help? Here are two screen shots of roughly equivalent code:
The larger the form, the more obvious the benefit.
The biggest thing is just using it in some applications, and writing some better test cases. I was banging my head against a wall today and yesterday over some pretty major stuff, so I'm sure there are a few other issues in there somewhere.
There are certain places where optimization would help significantly. Specifically on the dynamic class generation. Its generating a new class on each run. This isn't good. I have to sort out a problem with the Closure's owner, and then I can re-enable class caching. Today, though, a production implementation would probably run into trouble not too far down the road.
I haven't looked at the wicket-extensions at all.
I'm going to add GORM support from the Grails package. That is a really cool technology. Alternatively, we might be able to use Wicket as a render technology inside a grails app. Anybody know if this is possible? I have very little Grails experience.
Simplify the IDE and build procedure. This is one of those things that quickly turns off new users. Frustrating build experiences are bad.
Add some template applications. Set it up so getting off the ground takes little effort.
If anybody would like to pitch in, let me know.