java gui framework developed for tantivy ems system (october 1999 to august 2000)

Java GUI FrameworkJava GUI Framework Developed for Tantivy EMS System (October 1999 to August 2000)

Tantivy EMS ProjectTantivy EMS Project

• Element management system incorporating HP Open View, Configuration Server, Java GUIs.

• HP Openview used to provide visual status of Tantivy Network.

• GUIs used to drill down into each managed node (TSP) to provide management of the associated properties.


• Six GUIs were required and were to be developed by 3 engineers.

• All GUIs were to have the same look and feel.

• Deployment was Application and Applet.

• Development environment was NT/Solaris, Java 1.2 & Swing 1.1.


Content Pane

GUI FrameworkGUI Framework

• Advantages– Common look and feel– Central location for implementing common

logic– Code reuse– Maintainability– Easy to extend functionality across all GUIs


• Disadvantages– Some customisation to the project (ie. look and

feel follows that required by customer. This needs to be modified for use in other projects)


• Framework consists of a common package

• Package provides:– logic for displaying frames– dialog boxes– Splash screens, help about boxes etc.– common utilities (eg. logging, validation)


• Implementation– Subclassing

EquipmentViewFrame extends CommonFrame

MyTable extends CommonTable

where

CommonFrame extends JFrame

CommonTable extends JTable

– InterfacesMyTabbedPane extends JPanel implements CommonTabbedPanel

where

public interface CommonTab

Other DevelopmentsOther Developments

• Application/applet from one JAR file– One set of source provides an application and

an applet without any rebuilds.– The applet runs as a separate dialog to the

browser.– Code sample:

Other DevelopmentsOther DevelopmentsPublic class MyApp extends Japplet

{public MyApp() {

super();

}

public static void main(String[] args) {

MyApp app = new MyApp()

app.init();

app.start();

}

public void init() {

AppletContext ac = null;

try {

ac = getAppletContext();

} catch () {}

if(ac != null) { // applet }

else { // application }

MyFrame frame = new MyFrame(this, ac);

frame.setVisibile(true);

}

}

Other DevelopmentsOther Developments• Table Refresh Logic

– Table views may show large number of rows.

– Reduce amount of data retrieved from the Config Server by only getting those rows being displayed.

– Table refresh Logic:Get all indices

if Num indices != current indices

refresh whole table

if current index[] != new index[]

refresh whole table

else

get visible rows

refresh only those rows

Other DevelopmentsOther Developments• Real-time validation

– TextField class used to view/modify text– TextField class extended JTextField– Real-time validation for

• IP address (###.###.###)

• Domain Names

• Date/time strings (DD/MM/YYYY HH:MM:SS)

• length

• min/max values (for numeric fields)

• Character type - alphas, numeric, alphanumeric etc


• Real-time Validation (continued)– Text length, type determined from the MIB– MM_IDL modified to generate a static

FieldValidator class that contains all the possible MIB fields and their associated:

• type

• number of characters accepted

• min/max values


• Displaying MIB tables in dialogs– FieldFactory class used to create a TextField

class that provides:• label

• Tool tips

• Mouse over events (to expand text that doesn’t fit into text field)

• Validation

• Editable or readonly


• Displaying MIB tables in dialogs new Field("tspSystemId", "com.citr.utility.field.TextField", "String", "ID",

"Alphanumeric node name/id of the system as would appear in a hosts file",

Field.READWRITE, TSP_SYSTEM_LENGTH, "tspSystem")

– Reflection is used to create the widget


• Enumerations– Enumerations from the MIB/IDL managed by

Visibroker helper classes.– Helper classes allowed us to convert enum

values to their display strings.– BUT, for enumerations that were used in tables,

needed to pre-store enums & associated strings.– Code sample:

Other DevelopmentsOther Developments org.omg.CORBA.TypeCode[] typeCodes =

new org.omg.CORBA.TypeCode[fields.length];

for (int column=0; column < fields.length; column++) {

typeCodes[column] = null;

if(fields[column].getType().equalsIgnoreCase("enum")) {

try {

String helperName = fields[column].getDisplayType() + "Helper";

Class c = Class.forName(helperName);

Method typeCodeMethod;

typeCodeMethod = c.getMethod("type", null);

// Static method, don't need an actual object instance

typeCodes[column] = (org.omg.CORBA.TypeCode)

typeCodeMethod.invoke(null, null);

} catch (Exception e) {

logTraceMessage(log_C.INFO_TRACE_MASK,

"getEnumTypeCodes() ERROR while retrieving TypeCode for '" +

fields[column].getName() + "': " + e.toString());

}

}

}


• Timers & Threads for refreshing view– Use JTimer for GUI to refresh their data with

the Config Server. Interval is configurable.– Use of a thread which did a blocked CORBA

operation on the Config Server. When Config Server released the call, the GUI would poll the Config Server immediately. Light weight solution for providing immediate updates.


• Splash screens– Common Splash screen mechanism for display

of a graphic plus graphic object (eg JProgressBar)

– Splash screen displayed whilst frame being created


• Obfuscation– Provided by DashO-Pro v1.3– encrypts Java code so that it is harder to

decompile– Not 100% secure– DashO-Pro also provides renaming of classes &

methods, removal of unused classes to save space - gains of up to 60% compression

– Dash0-Pro available on Janus - /opt/dasho

Framework PitfallsFramework Pitfalls

• Making framework too common– use of a properties file - all properties must be

displayed for editing whether they make sense for the GUI or not.

• Development of framework was at the same time as the GUIs– resulted in some GUIs not using the framework

where it should have - extra time to bring it back in line

Framework PitfallsFramework Pitfalls

• Internationalisation– All messages, words etc should have used

ResourceBundles to make changing words easier and assist internationalisation.

– Associated with this is extra development effort.

Tantivy ResultsTantivy Results

• GUIs developed within the timeframe

• Happy with the design

• No major problems

ConclusionsConclusions

• Frameworks ensure consistent look and feel across many GUIs

• Provides location to pool common utilities to ensure utilities are only implemented once and not many times

• Look & feel changes can be quickly changed

The End!The End!

java gui framework developed for tantivy ems system (october 1999 to august 2000)

Documents