Flexible form management with dynamic object model
by: Wolf Siberski

The GEBOS series of banking projects developed at RWG in Stuttgart, Germany, which currently consists of about  3000 classes, includes a framework for form definition and management. This framework is based on a domain value type framework which allows easy addition of new domain specific value types to the system.

One of the goals of these frameworks is to make it possible to add and change forms between product releases. Therefore, both domain value types and forms are described in a dynamic

Domain values

The domain value framework allows the dynamic definition of new value types. There are about 30 static value types (e.g. alphanumeric key, date, amount, account number). Dynamic types are created by "configuring" one of these static types. The following properties can be defined:

These descriptions are stored in a value type repository which generates configuration files from the descriptions. These files are read at program startup. All values in the system are created by their name. The value objects delegate validity checks etc. to singletons which use the information in the configuration files for their respective services. Today we would use the type object pattern for this purpose.

Forms

In our domain many forms are used which have to be changed often due to changed business or legal requirements. Therefore the form is not

A form description consists of the following parts:

Products

One area our system supports is sale of investment products (savings plans etc.). A product consists of the following parts:

configuration information for a special product calculator (calculates increase of the invested capital)

Forms which have to be completed, printed and signed when selling the product.

Transaction forms which have to be filled and sent to the mainframe.

These products are also described dynamically and can be updated between product releases.

The input of values which appear on more than one form (e.g. customer name and address) is taken over to the other forms automatically. That also ensures consistency between all forms.

Design

(just begun, very incomplete)

Domain value framework

The client of the domain value framework just sees the value classes and the value factory. Most often the interface of the value superclass suffices. If special operations are needed (e.g. computation of the interest) a downcast has to be performed.

For creation of the value object the Product Trader pattern is exploited.

The value objects delegate validity checks, lettering service, etc. to domain value services.

Form framework

Known Problems