The majority of the configapp.jar is concerned with presenting the User Interface of the device configuration application. The majority of the code in this jar is found in the com.digi.config.ui package. Much of the underlying communication and device management classes are found in the common.jar shared library. See the javadoc for that library for more details on what classes are available and how to use them.
The paragraphs below will describe the general organization of the user interface as background information to developers looking to extend or modify that code.The ConfigAppPanel is the primary panel that is embedded inside of the application or applets frame. This panel is partitioned into several main components: the navigation (menu) area, the message area, and the content area. Each of these area's has an associated panel and the content area can have various configuration view panel's associated with it over time. When the user selects an item from the navigation panel, the action normally results in switching the content area to the view associated with that item. For example, clicking on the Home button will result in switching to the HomeView in the content area.
The class ConfigApp can be run as both an applet or as a standalone application. The class is run as an application by simply invoking main on the class.
The config applet has two modes of displaying menu's. The navigation panel is the default mode and this mode visually presents the menu in an Table of Contents on the left hand portion of the application window. The applet can alternately display the menu's in the traditional menubar style commonly found on windows and java applications. This mode can be enabled by specifying the UseMenus java property upon invocation.
The message area at the bottom of the config application screen displays information, warning, and error messages issued by the application. Any component in the application can issue these messages by using the SystemLog class found in config.jar. The SystemLog class includes helper methods for creating messages (SystemLogEntry) and places them in a log file and an in-memory collection (SystemLogCtlrImpl). The MessageArea class listens to the in-memory collection and displays them to the user. Application views reference message by a "message ID" and the SystemLog class looks up the appropriate message text from the applications message resource bundle file. This file contains the primary and secondary display text of the message as well as its severity. The MessageArea displays this appropriately.
Each View is stored in its own class. All views implement the ConfigView interface and typcially are derived from the ConfigViewImpl base class. Most views are displaying configuration data from the device and therefore access the Device class found in the common.jar library. This class provides methods to access the current settings and statistics on the device as well as methods to update the device configuration.
Views typically hold a reference to the Device object from the common.jar library. From this object, they normally get the current configuration settings they want to display in the view and store a copy of those settings in the view. As the view is edited, the updates are held in the view's local storage until the user indicates to save or cancel the changes. The ConfigViewImpl base class provides views a button panel that by default includes Save, Cancel, and Refresh buttons. This button panel can be overridden or removed but by default the buttons perform the following action:
Some views consist of a set of related views, each found on its own subtab. An example of this kind of view is the SerialView which has a variety of serial related tabbed panes. These composite style views extend the AggregateConfigView class which handles the management and display of the sub views. This class extends the ConfigViewImpl class so it also offers the Save, Cancel, and Refresh button panel. When the user performs one of these operations on an aggregate view, the operation is performed against all the subviews as well.
Views are instantiated and selected in the ConfigAppPanel class. Views are constructed on first touch in order to improve the startup time of the application.
The following resource files can be found in the package come.digi.config.resources
Custom applications that wish to make use of the common.jar services for managing resources can use the ConfigResource class to fetch various kinds of resources. This is a utility class that many of the other common classes use to locate application resources. Part of application initialization should be to inform the ConfigResource class of any application specific resource files using the loadXXXRb methods (ie loadUiTextRb, loadMsgTextRb, etc...). In this way, the common classes such as the SystemLog can find your resources and display them appropriately. See initialization in the ConfigApp class for an example of how to do the resource initialization.
Since resource files are packaged into the jar, they are not easily changed by the end user. Also, they are static in nature and thus cannot serve as a place to hold application preference settings such as screen colors, window sizes, fonts, etc... As a result, the ConfigSettings class in common.jar is useful for storing and retrieving these kinds of settings. This class maintains a config.ini file that holds user preference settings. This file is easily modified by the user and/or the application. At startup the application loads the ini file settings and displays the UI accordingly. The current configuration applet looks two places for ini file settings, first it checks the java user.home directory on the client system and then it checks on the web file system that the applet was loaded from. If neither of these files are found, then the settings defined in the class DefaultConfigSettings are used.