How It All Works
On start up of the application, the Extension Manager scans a predefined directory for extension descriptors. Upon scanning, the discovered extensions are registered and bound to the application. Application users will now see menu items and toolbars that expose custom extensions side-by-side with core features of the application. The menu items and toolbars will get their name and location from the extension descriptor (see Figure 2 for an illustration of how the extensions are scanned and bound to the application).

When clicking on a menu item or toolbar for an extension, an input dialog is generated based on the parameters in the descriptor (see Figure 3). A different type of GUI input widget will be used for each type of parameter. For example, a parameter of type boolean will be displayed as a checkbox (see Table 1).

After completing the input of the parameters and the user clicks OK, the following actions are taken (see Table 2):

1. The Jython environment is initialized by using the PythonInterpreter class.
2. All input parameters are placed onto the Jython memory heap, allowing extension developers direct access from the Jython script to the parameters. This is done by converting the Java input objects into PyObjects and passing them to the PythonInterpreter through the PythonInterpreter.set() method.
3. The Jython script is now executed using PythonInterpreter.execfile().

Write Jython Script
Before writing the script, the developer should know which parameters to expect in the script and what the functionality of the script should be. In general, the script will need to access the date that is in the core application.

The suggested way to do this is through a Java API exposed by the core product. This API should allow read and/or write access to information in the application. For example, if it is expected that a script will access Employee records, the API should provide methods to query and then access the information of a particular Employee record. The API should be well documented and with logical naming of classes and methods that reflect the parallel constructs in the application. It's very advisable that the Javadocs of the API are freely available. Developing scripts against a well-documented API is so much smoother than struggling with a badly written, undocumented API.

If the script needs to get further user input or display any messages/warnings, it can use the frame (of type JFrame) variable that is in the interpreter's scope as a starting point for creating new dialogs or windows.

Working Through an Example
Imagine a Human Resources management tool - HR Tracker. The tool manages a wide variety of HR details, in particular worker details and shifts that they work on. Doug's mega store would love to buy HR Tracker, but really needs the capability to generate worker attendance reports in Excel in the same format that the shift managers used to prepare by hand for old Doug for the past five years. We will go through the steps to develop the required extension.

First, we need to gather requirements that involve understanding what input is required for the report and what information is required in the report. Let's assume for Doug's report that we need to provide a start date, end date, department, and file name.

Next, we can write the descriptor XML file. It's advisable to use a commercial XML Editing tool so that the descriptor can be verified against the XML Schema. Listing 1 shows the descriptor file for our report. Once the script controller has scanned in this script, a menu item called "Generate Worker Attendance Report" will appear under the Reports menu in the application. When the menu item for this extension is selected, the dialog in Figure 4 would appear. Note that it can also be launched by pressing the F9 hotkey.

The generateWorkerAttendanceReport.py (see Listing 2) creates a report based on the parameters passed in. Note the usages of startDate, endDate, dep, and reportFile in the script. This script generates a simplified version of the report that Doug wants.

Conclusion
You should now understand the design of the Jython Extension Framework and how such a framework allows easy development of custom extensions to your rich GUI Java application. As you can see, once the framework is in place, the customer can quite freely enhance the product to include whatever features may be needed.

The reason that it is now easy for the customer to develop extensions is clear - we have relieved the customer from a lot of the work entailed in binding rich functionality to a GUI application. We have provided the customer with:

1. An easy-to-author descriptor to define input dialog and an entry point into the application with a built-in validation engine (i.e., the XSD).
2. A widely adopted object-oriented scripting language for developing scripts.
3. A well-documented Java API for accessing information within the core product.
4. A neat framework that brings it all together with minimal effort.

Remember, though, this does not come for free - a stable extension framework and a well-documented API together with good support is a must to make this work.

References

• Jython: www.jython.org
• XML Schema: www.w3.org/XML/Schema
• Eckel, B. Thinking in Patterns (chapter on Interpreters): http://mindview.net/Books/TIPatterns/