Sieben Geisslein - Developing in Feder

Niklas Mehner

October 3, 2007

1 Introduction

Feder is the development environment used to develop applications for Sieben Geisslein.

It aims not only at supporting the full development cycle including a vastly improved support for class evolution, but also at integrating code development with the creation and manipulation of the application data.

The problem with existing approaches to class (or in the RDMBMS world: table) evolution is, that much of the information about changes is lost during the development process. Migration scripts have to be created and much effort is put in keeping existing application data and the code using it synchronized. Updating an application to a newer version can become a major hurdle.

Feder solves this by capturing all refactoring information during development. Renaming a field is transparently handled as well as simple type changes.

Of course some changes still require writing migration code (e.g. splitting a field ``name'' into ``forename'' and ``lastname''). This is supported in Feder and all mirgration logic is included in the generated application. No scripts have to be run on installation, but all upgrades are still handled transparently.

Another domain that is almost completely ignored by existing IDEs is application data. Feder allows defining much of the data within in the IDE. This allows referencing this data from the application code in a way that can be validated during compile time.

Especially in GUI design the lack of support for creating data in existing IDEs has led to GUI designers to persist the GUI as generated source code. Feder persists the GUI structure as it is, without the need to convert it to source code and back again.

By providing solutions to these existing issues in development tools, I hope Feder helps improving developer productivity and removes some tedious and error prone tasks

2 Getting Started

Before starting Feder itself, a SiebenGeisslein server has to be running.

The distribution contains a script ``createDB.sh'' in the example directory that can be used to create a object store¹. After entering a user name and password, the script exits after creating an initially empty store.

sh createDB.sh
System user:
feder
System password:
secret
17.06.2005 20:49:24 org.siebengeisslein.Server <init>
INFO: Server ready.

After the data store has been created, the server can be started using the ``startDB.sh'' script:

sh startDB.sh
17.06.2005 20:50:20 org.siebengeisslein.Server main
INFO: Starting server ...
17.06.2005 20:50:20 org.siebengeisslein.net.ConnectionHandler <init>
INFO: ConnectionHandler listening on port 2903.
17.06.2005 20:50:20 org.siebengeisslein.Server <init>
INFO: Server ready.

Now Feder can be started using the ``startFeder.sh'' script. After entering the credentials used to create the object store in the login screen (figure 1) the main screen of Feder is displayed (figure 2).

**Figure 1:** Login Screen

**Figure 2:** Main Screen

3 Writing Classes

The Feder main screen consists of five components:

3.1 Package/Class Overview

The class list (figure 3) on the left hand side displays the packages and classes of the current project.

Packages can be added by pressing the ``Add package''-button () in the toolbar. Correspondingly classes can be added by pressing the ``Add class''-button () and removed by pressing the ``Remove''-button ().

A class is opened by a double-click.

**Figure 3:** Class List

3.2 Class Overview

The class overview (figure 4) allows to change the superclass of the current class and implement interfaces ².

**Figure 4:** Class Signature Panel

3.3 Method Panel

In the method panel (figure 5) the methods of the current class are listed. Methods can be added (

) or removed (

By clicking on a method, the method code is opened in the code panel. The visibility of the method can be changed by selecting a new value from the dropdown-box in the access column.

**Figure 5:** Method Panel

3.4 Field Panel

The field panel (figure 6) contains the fields of the current class. Field can be added (

) and removed (

The name can be changed by editing the table cell. Changes to the name are automatically reflected in the source code.

Each field has a read- and a write visibility. This determines the visibility of the getter respectivly setter that are generated for the field.

After changing the type of a class that has already been installed to the object store, a conversion expression has to be provided (see section 4).

**Figure 6:** Field Panel

3.5 Code Panel

The code panel (figure 7) contains the code editor and signature information of the current method.

Method parameters can be added () and removed (). The return type and method name can be set.

The code editor is not yet finished. Some statements/expressions can be inserted, others cannot. Please wait for the coming Feder versions for improvements.

**Figure 7:** Code Panel

4 Class Evolution

Feder currently supports the following class changes:

Adding a field.
Removing a field.
Renaming a field.
Renaming a class.
Changing the type of a field.

While the first four changes are handled transparently by Feder, the last change requires user interaction.

4.1 Type Changes

When the type of a field is changed in the field panel (figure 6), a type conversion expression has to be provided.

This is done by opening the migration view (figure 8) clicking on the migrate icon ().

**Figure 8:** Migration View

In the migration view for each type change a conversion expression has to be entered. Currently only the field itself can be referenced in the expression. Later versions of Feder will support referencing any field, that was present in the converted version of the class.

The first entry in the table is special in that it contains the initial value of the field. This is relevant for fields that are later added to the class. The field of the converted instances of the class will have this value as their initial value. The initial value does not affect instances created by any constructor.

As a quick fix a cast can be inserted by pressing ``Alt-C''. Unfortunatly the expression editor does not yet support writing casts directly.

5 GUI

5.1 Introduction

The GUI designer included in Feder is different from most existing GUI designers in that it directly manipulates the GUI components instead of generating source code for recreating the components when the application is started.

This makes the implementation of the GUI designer much easier, but also requires some conceptual changes. Even for a multi-user application each GUI component only exists once. This makes sense for the ``structure'' of the GUI (e.g. components contained by a panel), but not for the ``state'' (e.g. links to the model). Therefor links from the GUI structure to the state are modelled as ``User Local'' variables. User Local variables are (analogous to thread local variables) variables that have a different value for each user.

GUI components are made available to the application code as global variables. E.g. a frame can be made visible by the statement:

GUI.FRAME.frameName.show();

5.2 Frame Editor

5.3 Panel Editor

5.4 Action Editor

5.5 Switchpanel Editor

6 Data

7 Installing and Running Applications

Before installing an application some properties of the project have to be entered (Figure 9):

Id: The unique identification key of the project. This is used to identify the project. It should not be changed during the lifetime of a project.
Name: The name of the project. This can be arbitrarily chosen.
Description: A description of the project.
Start class: The class that is executed when the project is run. This class has to implement the ``org.siebengeisslein.application.Startable'' interface.
Classpath: Support of external libraries is not yet implemented.

**Figure 9:** Project properties

Once these properties have been filled, the application can be installed into the object store using the ``Install'' entry in the ``Project'' menu.

When aan application is installed into the object store for the first time, an instance of the class ``Start class'' is instantiated and persisted. Also all objects that are (transitively) referenced by the instance of the start class are persisted.

On subsequent installs, this instance is migrated to the new class version (see section 4 for details on class evolution). Referenced objects are migrated when they are loaded from the store.

After installing the application it can be run by selecting the ``Run'' entry in the ``Project'' menu. When an application is run, the ``start()'' method of the instance of the start class is invoked.

If a new version of the application ist installed after starting it, the running application is transparently upgraded.

8 Web Start Integration

Every application that is installed is also available through Java Web Start. The start page ( by default: http://localhost:8080) displays the list of installed applications (figure 10).

**Figure 10:** Web Start: Start Page

After clicking on an application link, a login dialog is displayed (figure 11) and the application is started.

**Figure 11:** Web Start: Application login dialog

Footnotes

... store ¹: Currently the start scripts are only provided for a unix shell. Windows start scripts will be provided in later versions
... interfaces ²: Currently only implementing the startable interface is supported.