Fun with IzPack

In the last cycle of our product at ${work}, I moved away from the custom installer I'd written and built one on IzPack. Overall I was pretty pleased. My original installer worked. Mostly. The new one a much more polished and did more. So there wasn't much to complain about. Except. None of my validators worked. As is the case with many software releases, there was too much to do to worry about it. The installer is almost always used by our internal staff so there wasn't too much concern about bad input. But still, that lack nagged at me. Last week saw the release of said version, and this week we begin, in earnest, all the design and requirements discussions trying to nail down the exact what and how of this cycle so there's not much focused programming going on just yet. The installer needed some other attention so I took a little time to figure out why none of the validators worked. IzPack is horrible about logging/tracing anything useful. In fact, if you look through the code, you'll see a lot of empty catch blocks. Go Team!

I set up IDEA so that I could run the installer in debug mode and step through the IzPack code and figure just what was dying. I was pleased to learn that IzPack craps out on validator messages if there is no langpack defined. You don't actually need anything in the langpack. It just has to be there. In your validator definition you can specify the exact message you want to display or if you want i18n support, you can give a resource ID. If IzPack can't find the ID, it defaults to just printing out that ID. So an empty langpack will (mostly) work just fine depending on how you define things. But if there is no langpack, you'll get an NPE so no dialog will show up but you also won't get any feedback at all for either failure. Once I saw that, it wasn't too hard to set up an empty langpack and viola! Validator feedback. Pure magic.

So, that's it. Set your langpacks. Enjoy the feedback. IzPack is not a bad piece of software, but could use some tender loving...

Groovy on the web the right way?

I've recently started (re)exploring the world of Groovy and, thus, Grails. The idea of Groovy makes me pretty happy, but Grails kinda makes me cry for a number of reasons. The entire system is, as you probably know, basically RoR but with Groovy complete with scaffolding. The issues with scaffolding are well documented. Most of the scaffolding gets thrown away once you start doing anything "real" and Grails can certainly suffer from that. You can, of course, write your own templates and these templates are basically JSPs implemented with a Groovy flavor. This is where my disappointment really starts to build. JSPs, at least in my circles, are all but deprecated. Even JSF2 is moving away from a JSP-centric view and moving on to JSFTemplating. So why did the Grails guys decide to reimplement JSP? But there's light at the end of the tunnel for me. There are two different projects that give me hope for using Groovy on the web tier: Gracelets and the Wicket Grails Plug-in. Both of these projects have two things going for them:

  1. They leverage existing frameworks and their component sets so we're not left reimplementing everything else as well.
  2. They use more component oriented approaches than JSP development tends to lead to.

I like the dynamic nature of Groovy and the fact you don't need to restart jetty every time you change a class. Maybe these options will make Groovy more palatable on the web. For me at least.

Qwicket 1.0

Qwicket 1.0 is finally here. Apart from being entirely too busy with work and sick children, I've been anxiously waiting along with everyone else for the 1.3 release to go final. This version features some streamlined build process improvements and a more interesting default UI. You'll likely end up building a new UI but at least there's enough there to work with while your design guys build something more customized. Part of the delay has come from some odd compiling and generation problems in my development environment but I appear to have ironed all those out. If you see something odd, please don't hesitate to let me know and I'll try to iron out any issues as quickly as possible. This release isn't entirely revolutionary but I hope to make some dramatic improvements over the next few months making Qwicket much more robust and to make it easier to base projects off of and track the changes as Qwicket evolves. I'd also like to add maven support and move to ant task and maven archetype based generation as that's a little lighter weight for something that (at least for the moment) you use to generate your project and then move on from.

Hopefully Qwicket will help you explore Wicket and get your projects running more quickly. If you have any requests, please feel free to file an RFE in the tracker.