Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Speed up your Swing GUI construction with better building blocks

Use two helper classes to reduce dialog development time

By David Fraser and Michael Harris, JavaWorld.com, 10/04/02

  • Print
  • Feedback
.

This article introduces two helper classes for speeding up the construction of Swing user interfaces. The idea is that these classes encapsulate the layout of form and data entry dialogs in a standard way. Specific dialogs can be quickly constructed by simply adding the necessary dialog fields to the two classes, without worrying about the layout of the fields.

The two classes are:

  • LabelledItemPanel: This class lays out items and their labels neatly on a panel
  • StandardDialog: This class provides the general look of dialogs and default button processing


These two classes leverage the fact that most dialogs used for entering information usually have the same basic layouts. Look at three dialogs for entering customer, product, and employee data:

Figure 1. Customer details dialog

Figure 2. Product details dialog

Figure 3. Employee details dialog

Each dialog has the same layout consisting of a list of labelled fields. Each field's layout is the same. The dialogs all have the normal Ok and Cancel buttons present on most data entry dialogs.

On our project, we achieved significant time savings as a result of using these classes instead of an IDE graphical user interface (GUI) builder. We had to build more than 20 dialogs for performing create, modify, and view operations on various data types. At the start of the project, a first version of the LabelledItemPanel and StandardDialog were built. Both classes had a few alignment problems. However, all the required panels and dialogs were created without programmers worrying about layout aspects. Further into the project, the alignment problems were solved in LabelledItemPanel and StandardDialog. All the panels and dialogs that used these two classes were rectified. This approach allowed developers to integrate the GUI with the application code much faster than if they were required to fully complete individual dialogs.

In this article, we compare our approach to the popular approach of using an IDE GUI builder. We explain how we came up with the idea for the classes and how they save development time. We describe our two classes and their usage in detail.

Note: Download this article's source code from Resources.

Using an IDE GUI builder

Most IDEs today have some sort of capability to construct user interfaces without writing much code. This is an attractive option to many developers because writing user interfaces from scratch can be complex. However, using an IDE GUI builder to build numerous windows or dialogs has its disadvantages. The next section explains these disadvantages.

The myth versus reality for large user interfaces

An IDE is a good tool when you need to build a simple GUI with only a small number of windows or dialogs. If you need to build a large number of windows or dialogs, then using an IDE GUI builder has the following disadvantages:

  • Unless you use simple layout managers or absolute positioning you still need to understand the complexities of various layout managers, especially GridBagLayout.

  • Each item on the dialog needs to be individually laid out, which involves setting a number of properties for each item. This makes it slow and tedious to lay out large numbers of dialogs or dialogs with many fields.

  • You cannot use the same layout over similar screens. Each new dialog needs to be laid out from scratch.

  • The generated code is generally not portable between IDEs and is sometimes not even compatible between different IDE versions. This is an important fact that must be considered in regards to code maintenance.

  • Dialogs are not easy to modify because the layout constraints are assigned to each item. If an item is moved, its constraints and all the other items' constraints affected by the moved item will need adjusting as well.

  • If there is a bug, looking through the generated code can be frightening, as generated code (in most cases) is not well laid out or readable. For example, the following is code generated by a popular IDE's GUI builder for a customer data entry panel: 
public class JBuilderPanel extends JPanel
{
  ...
  GridBagLayout gridBagLayout1 = new GridBagLayout();
  private JLabel myCustomerCodeLabel = new JLabel();
  private JTextField myCustomerCodeField = new JTextField();
  private JLabel myNameLabel = new JLabel();
  private JTextField myNameField = new JTextField();
  private JLabel myAddressLabel = new JLabel();
  private JScrollPane myAddressScrollpane = new JScrollPane();
  private JTextArea myAddressField = new JTextArea();
  ...

  public JBuilderPanel()
  {
    try
    {
      jbInit();
    }
    catch(Exception e)
    {
      e.printStackTrace();
    }
  }

  private void jbInit() throws Exception
  {
    this.setLayout(gridBagLayout1);
    this.setBorder(BorderFactory.createEtchedBorder());
    myCustomerCodeLabel.setText("Customer Code");
    myNameLabel.setText("Name");
    myAddressLabel.setText("Address");
    ...

    this.add(myCustomerCodeLabel, 
      new GridBagConstraints(0, 0, 1, 1, 0.0, 0.0,
        GridBagConstraints.NORTHEAST, GridBagConstraints.NONE,
        new Insets(10, 10, 0, 0), 0, 0));

   this.add(myCustomerCodeField,
     new GridBagConstraints(1, 0, 1, 1, 1.0, 0.0, 
       GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL,
       new Insets(10, 10, 0, 10), 0, 0));

   this.add(myNameLabel,
     new GridBagConstraints(0, 1, 1, 1, 0.0, 0.0,
       GridBagConstraints.NORTHEAST, GridBagConstraints.NONE,
       new Insets(10, 0, 0, 0), 0, 0));

   this.add(myNameField, 
     new GridBagConstraints(1, 1, 1, 1, 1.0, 0.0,
       GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL,
       new Insets(10, 10, 0, 10), 0, 0));

   this.add(myAddressLabel,
     new GridBagConstraints(0, 2, 1, 1, 0.0, 0.0,
       GridBagConstraints.NORTHEAST, GridBagConstraints.NONE,
       new Insets(10, 10, 0, 0), 0, 0));
   this.add(myAddressScrollpane,             
      new GridBagConstraints(1, 2, 1, 1, 1.0, 0.0,
        GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL,
        new Insets(10, 10, 0, 10), 0, 0));
        ...
    }

    ...
}


An alternative approach

At the start of our project we looked for alternatives to using an IDE to build the dialogs because we had many dialogs to build and were aware of the disadvantages described above. The only alternative was to hand code the dialogs and their associated panels. However, we were not going to be any better off simply using Swing's layout managers and components. We would end up producing similar code to the IDE with the same drawbacks. To speed up development we needed better building blocks (classes) that would take care of the dialogs' common aspects and be easily customized to handle the differences between screens.

  • Print
  • Feedback

Resources