Speed up your
Swing GUI construction with better building blocks
Tutorial Details:
Speed up your Swing GUI construction with better building blocks
Speed up your Swing GUI construction with better building blocks
By: By David Fraser and Michael Harris
Use two helper classes to reduce dialog development time
his 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.
What is common? What is different?
We determined the following three elements were common to most of our dialogs:
The dialogs usually consisted of a list of items and labels neatly aligned down the page
Each dialog normally had Ok and Cancel buttons
The actions performed when the Ok and Cancel buttons were pressed were usually the same
The differences between screens were the actual fields being edited and their labels.
Better building blocks
The most tedious part of developing the dialogs was specifying the layout constraints for each field and its label. The fastest way to develop is for the classes to allow us to specify the fields and their labels without specifying the layout constraints. It seemed to make sense to use two different classes: one for handling layout of the labelled fields and one for the common dialog buttons and associated processing. We called the class for layout handling LabelledItemPanel , while we called the class for the common dialog features StandardDialog .
A common panel: LabelledItemPanel
The purpose of LabelledItemPanel is to lay out items and their labels neatly on a panel. The class uses a GridBagLayout to control the actual layout, but this is all hidden from class users. To use the class, the item and its label are added to the panel with the addItem() method, passing the text for the field label and the field component. The user does not have to specify any layout constraints because the class works out all of the layout constraints needed.
The LabelledItemPanel can be used in two ways:
Create an instance of the LabelledItemPanel and add data entry fields to the panel
Subclass LabelledItemPanel and add the data entry fields to the panel during construction
An example of using LabelledItemPanel directly is shown in the following code fragment:
JTextField customerCodeField = new JTextField();
JTextField nameField = new JTextField();
JTextArea addressField = new JTextArea(3, 20);
...
LabelledItemPanel panel = new LabelledItemPanel()
panel.setBorder(BorderFactory.createEtchedBorder());
panel.addItem("Customer Code", customerCodeField);
panel.addItem("Name", nameField);
panel.addItem("Address", new JScrollPane(addressField,
JScrollPane.VERTICAL_SCROLLBAR_ALWAYS,
JScrollPane.HORIZONTAL_SCROLLBAR_NEVER));
...
// Display the panel to the User in a dialog
String customerCode = customerCodeField.getText();
String name = nameField.getText();
String address = addressField.getText();
...
// Process the data
If you compare the simple addItem() method calls with the IDE-generated code shown below, the time-saving advantages of using this class are quite obvious:
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));
An example of using the LabelledItemPanel by subclassing is shown in the following code fragm
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Speed up your
Swing GUI construction with better building blocks
View Tutorial: Speed up your
Swing GUI construction with better building blocks
Related
Tutorials:
|
JavaWorld - Distributed
applet-based
massively parallel processing
(DAMPP) - January
1997