This page describes the technical design of the EODiSP GUI base framework. For a more general overview, please see the EODiSP GUI Architecture page.

MVC Components

As described in the GUI Architecture, the EODiSP GUI base framework is based on a slightly modified model-view-controller architecture. The next figure shows the class diagram with the corresponding classes. Classes in white are part of the EODiSP GUI framework and classes in red are part of the standard Java Swing framework.

The names of the classes correspond to the parts in the MVC architecture. One notable difference is that there is an EodispApplicationController and an EodispController class. The EodispApplicationController is a container for EodispController classes and is responsible for their creation and management, such as adding and removing controllers. The controller classes in turn correspond to the controllers in the MVC architecture. Hence, they are responsible for creating and managing their frames and views.

Similar to the concept with the controller classes is the one for the frames in the GUI framework, although a bit more complicated. There is one EodispMainFrame and several EodispFrames and EodispViews. Especially the connection to the Java Swing classes might be a bit confusing, since the EodispMainFrame is derived from a JFrame whereas the EodispFrame indirectly holds a JPanel. This stems from the fact that the names of these Java Swing components does not correspond to the names in the MVC architecture, even though the concept is very similar. In Java Swing, a JFrame is the topmost container for a GUI application, or, in other words, it is the frame for the whole application. Several JPanels can be embedded in such a JFrame. A JPanel then displays a visual component (e.g. a JTree). Hence, in Java Swing there is only one JFrame, but several JPanels that embed visual components.

This concept is quite similar to the modified MVC architecture used in the EODiSP GUI framework. The names of the components are a bit different, though. The connection between the components of the Java Swing and the EODiSP GUI framework concerning frames and views is as follows:

• A JFrame correspond to a EodispMainFrame. There is only one such frame and it acts as the topmost container for the application, where several EodispFrames can be embedded.
• A JPanel correspond to a EodispFrame. An important difference to a JPanel in Java Swing is, that an EodispFrame acts as a management container for several EodispViews. This means, several EodispViews can be attached to an EodispFrame, where one of this views is the currently active view (i.e. the view which is displayed in the user interface).
• A visual component in Java Swing correspond to a EodispView. A view, however, has some additional functionality such as managing the connection to an EodispModel. It also has a back reference to the EodispFrame in which the view is embedded.

The SimpleInternalFrame is derived from the JPanel class and acts therefore as a frame in the EODiSP GUI framework. The purpose of this class is to extend the functionality of the EodispFrame with additional features such as a text bar which shows the title and an icon of the active view. It can also have its own tool bar.

The visual component that is displayed at a given time in an EodispFrame is retrieved from the currently active EodispView. This means, whenever the active view in a frame changes, the visual component that is displayed also changes automatically.

It is important to note that the visual placement of the frames is the responsibility of the EodispMainFrame. It has to know how to layout the frames in the application (at least the initial placement).

Visual Components

Visual components are these parts of the application which are able to show data from a model to a user. This can be a tree, a list, etc. These components are directly taken from the Java Swing framework. For the EODiSP GUI framework, each of these components is wrapped by an EODiSP component. This is done to insert some behaviour that is common to all EODiSP GUI applications in one place in the code. For instance, a JTree is wrapped by an EodispTree. This tree sets some behaviour, such as that it should not be editable, etc. In the EODiSP GUI framework, a visual component is referenced by a EodispView. This view can of course override this common behaviour if necessary.

Whenever a visual component is used in an EODiSP GUI application, a EODiSP wrapper class for the original Java Swing component should be used. This ensures that common behaviour can be set in one place instead of setting it for every instance of the component.

Actions

Actions are used to let a user interact with a GUI application. This can be done through the use of a menu bar, a tool bar, or a context menu. In an EODiSP application, all three possibilities can be used and are summarized as interaction interface. The management of this interaction interface is quite extensive since it must support many features. To handle this, the EODiSP GUI has extended the standard Java Swing Action interface to include additional information. This is the EodispAction class. In general, an action can be used to build all of the three possible interfaces included in the interaction interface. The EodispAction class includes information such as which interface shall be built upon it.

The following list summarizes the features that must be supported by an EodispAction.

• An action can be static or dynamic.
• A static action is always present, but can be enabled and disabled at runtime. It cannot be removed from the interaction interfaces.
• A dynamic action can be added or removed from the interaction interfaces at runtime.
• An action is either static or dynamic, but not both. This cannot be changed at runtime.
• An action can specify under which item it shall appear in the menu bar (including sub-menus).
• An action can specify in which interaction interface it shall appear.
• Every EodispView and every EodispFrame can declare which actions it provides.
• An action is only active and/or visible if the frame or view which declares it is visible.

To handle all of these features, an interaction management has been created for the EODiSP GUI base framework. It can handle contributions to any of the interaction interfaces from an ActionSourceHandler (an interface which is implemented by all classes that want to contribute to the interaction interface), and is able to create a complete tool bar and menu bar which can be displayed by the EodispMainFrame. Figure 2 shows the class diagram of the interaction management. The white classes are part of the EODiSP GUI base framework and the red classes are part of the Java Swing framework.

The important parts of the interaction management are the EodispMenuManager and the EodispActionRegistry. The EodispMenuManager class is responsible for creating the menu and the tool bar. In order to be able to create the menu and tool bar, it uses the data from the EodispActionRegistry class. This class is a registry for all EodispActions (i.e. static and dynamic) in the EODiSP GUI. Whenever an action is added, removed, or otherwise altered, the registry will fire an event. The EodispMenuManger catches the event by implementing the EodispActionListener class. Whenever such an event occurs, the EodispMenuManager updates the menu and tool bar as needed.

There is one special action that needs to be mentioned. This is the EmfAction. This is a dynamic action especially used for EMF commands. It works together with the EMF edit code that is generated to handle XML model data (e.g. an application's project file). An EmfAction is always dynamic and holds an EMF command that can be executed on the EMF's command stack. Such a command might be adding or removing a model item from the model. Furthermore, EmfActions are always created at runtime whenever one is needed. This will ensure that only those actions are available through the interaction interface which can be executed on the model. For example, if a node in the project's tree is selected, only EmfActions for adding valid children will be created.

Execution Sequence

Figure 3 shows a sequence diagram which illustrates the starting sequence of an EODiSP GUI application. The instances shown in the sequence diagram might be a bit confusing or misleading since it shows instances of the base classes from the EODiSP GUI framework. In reality, these instances are instances of a concrete application. For example, the instance of an EodispModel could be the SMProjectTreeModel. This would be the real component serving as a model for the tree showing data from the simulation manager project file. Although this instances might be incorrect, the starting sequence remains the same. This, hopefully, is less confusing than introducing new classes.

The sequence in the figure first shows the creation of an EodispApplicationController. This instance is created by the an EodispAppBase instance. The EodispApplicationController is responsible for creating the EodispMainFrame and all EodispControllers of the application. An EodispController in turn creates its EodispFrames, EodispViews, and the EodispModels and connects them together.

After everything has been created, the EodispMainFrame adds the tool and menu bar, layout all frames as appropriate and shows itself on the screen.

The sequence diagram shows only the most important method calls to start an application. It explains how the MVC components are connected together and how they are created.