310 likes | 345 Vues
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.
E N D
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.
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