Finally… Client Properties You Can Use

One of the Java Swing GUI toolkit’s strong advantages is its flexible, easy-to-customize architecture. Swing isn’t easy for beginners, but once you grok it, there are a lot of great ways to customize the behavior, state, and appearance of a widget. Indeed, if maximum flexibility is your goal, you’d be hard-pressed to find a better toolkit on any platform.

I used to hand-code all of my Swing code, including UI layouts. Thankfully, over the past year or two, several high-quality graphical UI layout tools have emerged, the first of which (that I noticed) was JFormDesigner — which I still use. But there’s one feature I really miss from the current generation: client property support.

I find myself constantly using client properties to extend the functionality of Swing components. For example, I’m a big fan of externalized formatting for Swing components, like what Guy Romain is doing with the Fuse project. While Fuse is annotation based, I’m a simpler guy — I want to be able to define properties of Swing components in an external file (very much like a CSS file) and then apply those styles to Swing components by id (which I map to the JComponent’s name property) and by “class”. So, I can do something like:

JTextField.productCode {
    columns = 10;
    fontSize = 10pt;
    font-family = Helvetica,Arial,Dialog;
    border: 1dlu solid black;
}

and map that to all JTextField’s with the “productCode” class. Ah, so how do I assign the productCode class to a component? Subclassing is of course a bad idea. I maintain that you should never, ever subclass Swing components to add general functionality to them (if you ever hope to leverage a single third-party component).

The answer, of course, is a client property. I can define a client property key “org.galbraiths.clarity.styleClass” and set the value to “productCode“, and I’ve now got this great system for allowing all JComponent’s to specify a class for styling. (I actually apply the styles via a decoration mechanism that applies to all component hierarchies before they are displayed, but that’s another story.)

Alas, the current versions of JFormDesigner, NetBeans, and IDEA don’t provide any support for setting client properties. Ugh. So I have to write some kind of custom code all over the place to do this, which I’m loathe to do. I suppose I could, but, frankly, it makes my WinForms developer friends laugh at me, and I hate that.

Fortunately, that’s about to change. The next version of JFormDesigner introduces support for client properties. You go into the Preferences menu and define your standard client property keys, like so:

and then the property pallette lets you set those values:

Nice! I’m one step closer to my dream development environment for my Swing framework. The next version of IDEA’s GUI builder will also support client properties; hopefully, NetBeans will too.

By the way, I’ll be talking more about this, and will be sharing some of my code under a license anyone can use, at this year’s JavaOne in my Swing session. If I’ve said something you particularly disagree with, make a rude comment to this blog, by all means, but even better — come and heckle! Chet can’t be the only one with rabble-rousers in the audience.