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

Java GUI Framework
Developed for Tantivy EMS System
(October 1999 to August 2000)
Tantivy 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.
Tantivy EMS Project
• 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.
Tantivy EMS Project
Content Pane
Tantivy EMS Project
Tantivy EMS Project
Tantivy EMS Project
Tantivy EMS Project
Tantivy EMS Project
GUI Framework
• Advantages
– Common look and feel
– Central location for implementing common
logic
– Code reuse
– Maintainability
– Easy to extend functionality across all GUIs
GUI Framework
• 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)
GUI Framework
• 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)
GUI Framework
• Implementation
– Subclassing
EquipmentViewFrame extends CommonFrame
MyTable extends CommonTable
where
CommonFrame extends JFrame
CommonTable extends JTable
– Interfaces
MyTabbedPane extends JPanel implements CommonTabbedPanel
where
public interface CommonTab
Other 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 Developments
Public 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 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 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
Other Developments
• 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
Other Developments
• 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
Other Developments
• 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
Other Developments
• 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 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());
}
}
}
Other Developments
• 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.
Other Developments
• Splash screens
– Common Splash screen mechanism for display
of a graphic plus graphic object (eg
JProgressBar)
– Splash screen displayed whilst frame being
created
Other Developments
• 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 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 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 Results
• GUIs developed within the timeframe
• Happy with the design
• No major problems
Conclusions
• 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!