The GUI and EMF

Since the crucial feature of an EODiSP GUI application is the manipulation of its project file, the implementation for manipulating XML files is also crucial. Instead of implementing an own mechanism for XML manipulation, the EODiSP assigns this task to the EMF framework. EMF is a code generation facility for building tools based on a structured data model, such as XML. Therefore, it is well suited for this task. The code generated by EMF is split into three parts:

1. The model code: This code is a representation of the actual model (i.e. the XML file).
2. The edit code: This code is built on top of the model code and facilitates the manipulation of the model by providing commands such as insert object, delete object, undo and redo commands, etc.
3. The editor code: This code generates either an eclipse plug-in or a rich client application. It is built on top of the edit code and provides a complete solution to edit the model in a graphical environment.

This possibilities are tempting, and in fact, the EODiSP uses the first two parts of the above mentioned list, the model and the edit code, to manipulate the XML data. The third part of the EMF generation process, however, is not used by the EODiSP GUI. This stems from the fact that one requirement for the EODiSP is, that it shall run under as many platforms as possible. The problem with this requirement and the generated EMF editor code is, that it depends on the eclipse platform, which is not platform independent. As a matter of fact, the eclipse platform runs on many platforms, but the decision has been taken to use pure Java for the implementation of the EODiSP, which runs on even more platforms. As a consequence, the decision felt on using Java Swing for the implementation of the EODiSP GUI.

Figure 1 shows the connection between the Java Swing and the EMF framework. It shows that the EODiSP uses the model code and the edit code generated by the EMF framework. The editor code, however, cannot be used because it does not use the Swing graphic library, but the SWT library instead. For the reasons mentioned above, the EODiSP privileges the Swing graphic library. Since the interface of the SWT components and the Swing components are different and because EMF provides code generation for the SWT library only, there arises the need to wrap the generated EMF code to make it usable for the Swing library. This is done in the EODiSP model code. It uses the generated EMF code to access the actual model data. It then transforms this data and exposes an interface to the transformed data which is usable by the swing components.

Figure 1: The connection between EMF and Java Swing.

Base Framework

Since many design considerations are very similar for each and every GUI application, the two EODiSP applications are instantiated from a base GUI framework that has been developed for the EODiSP. The base framework has been implemented from scratch and is a lightweight implementation following a slightly modified version of the MVC pattern. The decision not to use an existing GUI framework for the EODiSP has been made in order to have a framework that has as few dependencies as possible and to exactly reflect the needs for the EODiSP at the same time.

The MVC Pattern

The Model-View-Controller pattern is a widely used pattern in GUI frameworks and envisages three main components; The model, the controller and the views. It is used to separate an application's data model, user interface and control logic into three distinct components. The three main components can be described as follows:

• The model: A domain specific representation of information. The information itself is usually stored persistently (e.g. in a database or in a file). The model adds meaning to this data by providing mechanism to work with it.
• The view: This is the component that presents the data held by the model to the user. This is typically a user interface element. Several views can access the same model data and represent it.
• The controller: This is the component that receives events (such as a click on a menu item) and processes them. It invokes changes on the model, and sometimes also on the view.

Figure 2: The original Model-View-Controller Pattern

Using this architecture to build a GUI framework assures that the components are decoupled. It is also a good architecture to ensure maintainability of the code even if the code base grows.

The MVC Pattern adapted for the EODiSP GUI

The EODiSP GUI framework is implemented on the basis of a slightly modified MVC architecture. The difference is only in the view component, where an additional component has been added. This additional component is the frame.

The idea behind a frame is, that it is a container for several views. It is able to manage these views independently, releasing the controller component from this task. The functionality of a frame can be summarized as follows:

• It is a container for several views.
• It can set, unset, or change the currently active view.
• It knows how to display a view component.
• It defines the overall look and feel.

Hence, the frame is actually the view component in the sense of the original MVC architecture. Therefore, the addition would rather be that the view component has been degraded to be only a component that can display data from the model. As an analogy, the frame can be considered as a picture's frame, whereas the view would be the picture itself. Since it is a modern picture frame, the picture in the frame can be replaced by another picture.

Using frames as containers for views creates new possibilities. For instance, a view can be displayed in another frame without much work, or if a frame is disposed, it will dispose all included views automatically.

Figure 3 shows the structure of the MVC architecture as it is used in the EODiSP GUI base framework. Apart from the frame component which has been added, it is identical to the original MVC pattern.

Figure 3: The Model-View-Controller Pattern as it has been adapted for the EODiSP

It should be noted that this architecture allows a controller to send commands directly to a view. This can be useful in some situations (e.g. to send a command to update the registered actions). However, whenever a command involves the view's model, it is considered as a more structured way if controllers send their command only to the models, which in turn update the views by sending a notification.

Interactions with the User

Another important feature of a GUI application are the interactions with the user. For the EODiSP GUI, these interactions are mostly done through actions. Actions can appear as a menu bar item, a tool bar item, or as an entry in the context menu. In this documentation, we will refer to all of these item as the interaction interface. Apart from actions, obvious interaction components such as text boxes, etc. are also supported. Because the interesting part are the actions, they are described here a bit more detailed.

Actions are a Java Swing construct which can be used to define centralized control of functionality. Hence, actions can be used to create an item in an interaction interface with only one instance of an action. For instance, an action can declare an "OnExit" functionality, which is available from the menu bar and the tool bar. Whenever the action is performed, the same code will be executed.

Handling these actions is quite a large task for a GUI application. For this reason, the EODiSP GUI base framework has a built-in lightweight interaction interface management. It is described in more detail in the Actions section of the GUI Design page