Property files are frequently used in systems built using Java whether it's a thick Java client, a servlet, or a business component. Java specifies the format for a property file and provides the Properties class to read from and write to these files. However, Java is silent on the aspects related to validations of a value entered in a property file, providing room for errors to creep into an application system. How many times have you started to debug a failure in an application only to realize that it's because of an incorrect value in a property file?

The Properties Editor Framework detailed in this article was developed to solve the problem of managing application properties. It provides a convenient way to define a data type for each property and have a companion component in Swing to edit the property value. The framework can be used as a standalone tool or as part of a user interface.

One of the framework's design criteria was that it should work out of a property file, i.e., no other files or databases should be required for managing the property file. This is achieved by using certain meta-attributes to describe the characteristics of each property in the properties file. These meta-attributes are embedded along with each property in the property file as comments (Any line, in a property file, starting with '#' is considered a comment in Java).

In this article, we'll describe the framework's use, the concept of meta-attributes, and the default set of the attributes supported by the framework. And then, we'll explain the framework's design and how to extend it to support a new property data type.

Using the Property Editor Framework
The first step in using the Property Editor Framework is to decide on the Parameter type of each property in the properties file. Currently the framework supports the types listed in Table 1.

The next step is to modify the properties file and add the necessary meta-attributes for each property. Listing 1 shows a sample properties file with meta-attributes.

The final step is to set up the environment for the Property Editor Framework and invoke the Property Editor Dialog to start updating the property values. Figure 1 shows the properties as rendered in the Property editor Dialog.

Meta-Attributes Explained
The basic meta-attributes speci-fied by the framework for each property are Parameter Type, Editable, and Documentation. The Parameter Type represents the type of a property. It's used to render a suitable component for editing the property value. The table below lists the components rendered for the each of the possible values of PARAMETER TYPE.

The meta-attribute EDITABLE indicates whether the user can edit the value of a property. In the Property Editor Dialog, only properties that have a true value for EDITABLE meta-attribute are displayed. This lets the application developer make certain attributes in a property file not editable through the dialog.

The DOCUMENTATION meta-attribute specifies the text (which can be specified using HTML) that provides assistance to the end user while editing any particular property. In Figure 1, this documentation is displayed below the JTable con-taining the editable properties. As HTML tags are accepted, the <A> anchor tag can be used to provide a link to more comprehensive documentation.

Apart from the basic meta-attributes, there are two special meta-attributes. First one, GROUP NAME, is used to group related properties together. In the Property Editor Dialog, each property group is displayed in a separate tab. This could be used to group your attributes into, say, 'Basic' and 'Advanced.' Note that this parameter shouldn't be specified for each property separately. Once a GROUP NAME tag appears, all the parameters till the next GROUP NAME tag are grouped together. Another special meta-attribute is ALLOWED VALUES, which is used in conjunction with the SYMBOL parameter type. This lets you specify the list of valid choices for a SYMBOL property. These values should be separated by commas.

Adding Meta-Attributes
Now that we have a good idea about meta-attributes, let's walk through the steps in adding them to the Property File. Consider the following set of Properties.

LoggingEnabled
LoggingLevel
LogFile
DatabaseURI
DatabaseUser
DatabasePassword

Step 1: Decide the Grouping of the Properties
In the example the properties can be split into two groups based on their purpose, Logging and Database connection. Let's call these groups Logging and Database.

#GROUPNAME = Database
# GROUPNAME = Logging

Step 2: Decide on the Type for Each Property
In the example above, the types to be assigned to each property are shown in Table 3.

Step 3: Add Meta-Attributes to Each Property
The complete listing of this sample is available for download along with the source (see Listing 2).

Design of the Property Editor Framework
In this section, we will detail the design of the Properties Editor Framework. To reduce complexity, we'll break the discussion into: Creating the model of the Properties Editor component, creating the UI of the Properties Editor component, and the framework's persistence mechanism for the properties file.

Creating the Model
The classes involved in reading the properties file into memory and creating the data model are depicted in Figure 2.

The EditorFile class, which ex-tends the File class, is used as a thin wrapper for the Properties file. The EditorFile class provides the facility to add an Observer, which will be notified when changes are made to the property values.

The Parser class is a simple line parser that reads data from the EditorFile instance line-by-line and creates an in-memory model of the property file. It also defines the regular expression patterns to match the different meta-attributes supported by the framework. This class creates a new instance of Group class each time the meta-attribute '#GROUP NAME = <Group Name>' is encountered.

For each property key-value that falls under the same #GROUP NAME, an instance of one of the sub-classes of the Parameter class hierarchy is created. The exact sub-class is decided by the value of the meta-attribute #PARAMETER TYPE, which also keeps track of the value of meta-attribute EDITABLE that's used later by the view to decide whether to make it visible.

Creating the User Interface
The classes involved in rendering the user interface of the component are depicted Figure 3.

Referring to Figure 1, the visual area of the dialog is split between the Panel used to render the table of property key-value pairs and the JEditorPane showing the documentation text of different properties.