Filling the Gaps in Swing...

I had this subject on my backlog for quite some time. You see, I started my days as a professional Java Developer doing Swing coding. At that time Swing was OK, a little slow, but OK. Today I believe Swing is as fast and any other GUI Toolkit for Java with the advantage of being extremely flexible. But I don't want to get into a GUI Toolkit debate here because I think there is nothing to debate: you weight the factors for the project, choose a toolkit and live with it.

In the last couple of days I stumbled upon two very interesting Java Specification Requests (JSR) related to Swing The first and oldest one is the JSR 295 - Beans Binding. The second one is the JSR 296 - Swing Application Framework. I already heard about the first one a year ago and I actually thought it was dead, but there has been some progress. These JSRs fill some of the Gaps I always believed Swing had. I'll give you some details.

The Beans Binding JSR finally turns Java Beans into something really useful. The idea is simple: you have two Java Beans and you want to bind their properties. You want that when property X of bean A is changed then the property X of bean B is also changed. Of course that you want this binding to work both ways. Simple in principle, but easy to do? Probably not, but look at the potential: you have a JTextField and its "text" property; you have your own bean, Person, with a "name" property; you simply bind the two properties together and voi lá: the name of the Person is displayed in the JTextField and when you update the JTextField the name of the Person is also updated.

JRS 295 - Beans Binding goes far beyond this simple Use Case I described, it even has an expression language for complex operations and artificial properties to help use the Swing components more effectively. For instance: the JTable class has an artificial "elements" property that represents the rows in the table - this way you can bind a list of objects to a JTable. If your curious check this blog entry and dig in.

Waht about JSR 296 - Swing Application Framework? How should I put it: if you didn't do something similar yourself when you developed your Swing interface that you're in real trouble!!! Let me explain: Action management is something that you must learn if you want to make a clean Swing Interface. Don't know what I'm talking about? Well, you're in real trouble. I'll help you: I'm talking about extending the AbstractAction class. It may seem strange but the idea is simple: you create an action and use it for your menus, buttons and pop-up menus. This way you have only one point on your code where you define the icon for the action, the text, the tool tip, the accelerator key and so on. When you add the action to a menu Swing will automatically take advantage of all the properties. When you select the action, be it in an application menu bar, pop-up menu or tool bar, the same actionPerformed method is used: the one of the action.

But believe me that you loose some time creating the structure to get your Actions well together, specially if you want to have ActionMaps and the standard Copy/Cut/Paste actions. And there comes JSR 296 to the request. With it you simply annotate the methods that are supposed to be actions and it takes care of the rest. Even the GUI builders like NetBeans Matisse will support this.

But the JSR 296 goes beyond this and it event provides support for background Task execution with the same @Action annotation. These background tasks can also provide a progress status and messages that can be displayed in a Status Bar. But another interesting thing is the support for Resource Management. The idea is that instead of setting all properties of a Swing component when it is created you simply set is Name property and then the resources define the rest. For instance, you set the name of a JLabel and in the resources you can define the value for its Text, Background Color, Icon, Orientation properties, or any other property for that matter. This keeps code clean of any string or resource that doesn't belong there.

For more details on JSR 296 - Swing Application Framework, check its development site, specially the introduction.

Now, if you're just on of those Eye Candy Lovers you can have a look on how the new Progress Dialog for the Java Plug-in will Look in the Java 6 Update 1 or Java 7. Now you have something decent to show your users when they are waiting for an Applet to load. In fact, you can even set the image you want to show.

Comments

Popular posts from this blog

Back to C: CMake and CUnit

OpenClock and Gentoo

Gentoo with LUKS and LVM