Provides the internal frames and standard panels for handling the CRUD operations on the database objects, for the Access Road desktop. It manages the main window. It is used by the Gui2 package which is responsible for handling GraphicViews and Trees.
Generally speaking, the Access Road software is based on a solid object-oriented design. The best way to provide reliable software at the best cost is to concentrate the efforts on clear and structured data, clear and structured patterns, clear and structured documentation. The Access Road classes are first Plain-Old Java Objects (POJO), because we think that structured POJO is the proven way to have great software. Interfaces and methods are stable, and their generic nature provides high-level operations. Some robust coding patterns may then appear through the repeated use of these classes in varied contexts, in an iterative process.
Several coding patterns have so emerged during the Access Road development, even if they are not always fully presented as pattern in the Java class documentation:
The little decision maker pattern in the gDMak package is responsible to manage the basic operations from the events of the menu.
The little internal frame pattern in the Gui1 package is responsible to handle the internal frames in the Access Road desktop.
The gBaseBeanInfo package applies an extended JavaBean pattern called the BeanInfoPattern, to set the handling of gBase objects in the GUI. This pattern covers the display of each property of the base object in the right GUI editor, and the policy to create, edit and delete the property. It uses the Java reflection, and it is applied mainly by the gBaseBeanInfo and the Gui1 packages.
The embedded class pattern provides a form of multiple class inheritance for the classes in the gBase packages.
The event management pattern for the views is responsible to update a displayed view when a relevant property is changing, from a view node or an intermediate node in any access path of the view. It is described in the documentation of Gui2.GraphicViewBaseListener.
The thread management pattern for the views is responsible to provide a dedicated thread to each displayed view, for processing its own access path searches.
The access path search pattern is the most complex one. It includes mainly the generic gWork package and the AcsAddon gWork packages which contain the search algorithms. There is also the Gui2 package with the GraphicViews, and the CNot package which contains the notification interfaces and classes used for the data flow between the gWork packages and the GUI-oriented packages.
The pattern for the AcsAddons is explicit and well documented, covering the coding for each of the classes and methods which belong to it. It is mainly implemented in the gBase and the gWork packages. This pattern allows to add more easily some Java classes to do specific gBase and gWork functions.
As a framework for simulators, Access Road needs to offer all these coding patterns. It provides powerful capacities to simulate a new software, and to integrate it into the GUI and into the other simulations.
It is important that the GUI offers a standard display and standard operations for all the current and future simulations, whatever the characteristics they have. The principle of clear and structured coded concepts is then extended to the GUI. This is a complex requirement, but it will be fulfilled only when the GUI will appear to the user as a simple extension of its proper way of think. The complexity of the concepts and operations is masked by default, in all the possible ways. The GUI displays only the needed windows to operate, and a window works independently from most of the other windows, with its own commands the user may learn gradually. This is why the main menu is so simple, without buttons. This is also why a generic set of operations has been defined for the GUI, as an image of the set of concepts Access Road handles in its generic database. This allows a new user to operate on Access Road with a minimal experience, whatever the software is want to simulate. He has just to understand some generic concepts, to know how to use the explorer and the beamer windows, and how to handle some basic commands in the main menu.
According to a classical Model-View-Controller pattern, Model is implemented mainly by the gBase package, and the Gui1 package contains View and Controller classes. Indeed, it is more true to say that there are 2 levels of Models, 5 levels of Views and 3 levels of Controllers. Even if they are sometimes in the same class, this set offers a complex but powerful platform to manage the first level of GUI objects. It implements the framework for the internal frames in the desktop, and it is also based on the BeanInfoPattern framework form the Pattern package. The implied classes in the Gui1 package are listed hereinafter:
the Models are in the gBase and gBaseBeanInfo packages for all the database, and there is also InternalFrameModel for the frames in the main Access Road window,
the Views are, from the bottom to the top: Desktop, InternalFrame, CommonPropertyEditor and its subclasses, BaseObjectHandler for creating BaseObjects, DialogBox for user dialogs,
the Controllers are all the classes of the package gDMak for acting on the base objects, BeamerManager for managing editors - that are CommonPropertyEditor and its subclasses -, and BaseObjectHandler for creating BaseObjects,
BeamerManager and BaseObjectHandler use the BeanInfoPattern to interact with gBase classes under the control of the gBaseBeanInfo classes. These classes define how the Gui1 package has to display and edit each property in a gBase class.
InternalFrame is responsible to built up and manage all the internal frames in the desktop. It works on the explorer frame, the ACS frames, the view frames, the diagram frames, the text frames, the 'All Views' frames and the structure frame.
DialogBox is responsible to built up the short dialog boxes in the desktop. According to the Model-View-Controller pattern, it is a View used by BeamerManager, CommonPropertyEditor and its subclasses, BaseObjectHandler, and numerous gDMak.Action classes. The typical methods allows to display a message, a list for the user choice, or check boxes and fields. It is possible to select simple or complex typed objects in the explorer. Tip: to understand the executing paths from the DialogBox to the property editors and the gBase objects, it is easy to produce an error on the allowed value of an editing method, so that the sequence of called methods is displayed in the console.
BeamerManager in the Gui1 package is a complex class which displays and edits the properties of an object in some matched tabbed panes, following the BeanInfoPattern framework. It is responsible for managing the property editors for all the ARoad0.gBaseInterface.BaseObjects, with their layouts in the tabbed panes. It does this work both for the beamer frame, the ACSFactoryImpl frame, the structure frame, and the Gui2.GraphicViewPropertyEditor for the 'All full views' and 'All NoThan views' frames. The varied ARoad0.Gui2.PropertyEditors are responsible to display varied types of properties, like a string field, a checked box, a list or a map with strings or more complex objects. A title and some buttons may be included in the displaying, and there is a common look-and-feel for all. Gui2.GraphicViewPropertyEditor is a special case that handles a GraphicView and a JtextPane.
As an application of the BeanInfoPettern framework, BeamerManager integrates all the property editors of this Gui1 package. The editors are presented hereinafter:
CommonPropertyEditor is an interface which extends javax.bean.PropertyEditor. It defines constants and common methods. All the Gui1 property editors implements this interface. Its getCustomEditor() method returns a JPanel that BeamerManager integrates, and which allows the user to read and edit the current property value.
SimplePropertyEditor displays and edits a simple property in a gBase class, that is those having the types boolean, int, String, ARoad0.gBase.ImmutableName and ARoad0.gBase.BaseObject. Object is not an allowed type. This class is the superclass of all the other Gui1 property editors, and it provides common methods to all of them. Rather than to be a property change provider, as any javax.bean.PropertyEditor, SimplePropertyEditor is a an effective PropertyChangeListener of the updates in the property it displays.
CollectionPropertyEditor is a subclass of SimplePropertyEditor. It handles the properties having the types String, ARaod0.gBaseInterface.BaseObject, ARaod0.gBaseInterface.ImmutableName arrays, java.util.Collection and java.util.Map, where the values in the Map or the Collection are Strings, ARaod0.gBaseInterface.Names or ARaod0.gBaseInterface.BaseObjects. For a Map, only the BaseObject values are displayed, and there is no updating.
StringMapPropertyEditor is a subclass of SimplePropertyEditor. It handles the properties having the type java.util.Map, where the keys are free Strings and the values are only String arrays.
StringTwoKeysMapPropertyEditor is a subclass of StringMapPropertyEditor. It handles the properties having the type java.util.Map, where the keys have a constrained first part, and an user-defined sub-key, and where the values are constrained Strings.
BaseObjectMapPropertyEditor is another subclass of StringMapPropertyEditor. It handles the properties having the type java.util.Map, where the String keys may be very structured ones, and where the values are BaseObject or ImmutableName arrays.
RightMapPropertyEditor is a subclass of BaseObjectMapPropertyEditor. It handles the properties having the type java.util.Map, where the String keys may be very structured ones, and where the values are StringRight arrays.
AssociationMapPropertyEditor is a subclass of StringTwoKeysMapPropertyEditor. It handles the property types like its superclass. It is used by ARoad0.gBase.ACSFactoryImpl to define in a small language the list of actions (or associations) gBase.AssociateUtilityImpl has to perform when a new object is created in an ACS, or to create some root objects in its parent ACS.
BaseObjectHandler in the Gui1 package is responsible for creating or copying a BaseObject instance, excepting for an ACS or a ViewInBase. In the MVC pattern, this is the controller that handles all the user dialogs to define the parameters before the operation. The BaseObject class methods to use in the operation are declared in the BeanInfo class which is associated to the gBase class of the object to handle, in the gBaseBeanInfo package.
The performance of the Access Road GUI, in the 0.7.0 version, has some limits. They are presented hereinafter:
The AcsAddon pattern allow to strenghten the facilities of the packages gBase and gWork to simulate complex software, but it is not possible to define specific GUI features for a given ACS addon.
Ease-of-use: medium. The package is well structured, numerous controls check in the method arguments, and the classes may be easily derived to extend the functions; some methods are quite complex. The interactions gBase/gBaseBeanInfo/PropertyEditor/BaseObjectHandler are complex.
Reliability: medium-high. The execution paths have been well tested in the GUI.