Application Logic Manager (ALM)

The application logic manager is a generic component that controls most of the actions necessary when providing an application. Many of the generic features of the application logic manager are referring to features provided by ODABA. Thus, ALM reacts on database events in order to refresh data displayed on the GUI, it automatically detects base collections for drop lists (not only for enumerated attributes) and it determines proper forms to be displayed in the application. Since ODABA provides a fat ALM, application components become very thin.

Thus, the ALM reduces the burden for the application developer extremely and application development can concentrate on presentation rule.

When providing resource definitions for the ALM, rules differ a little bit from other systems. The ALM does not distinguish between forms and controls, i.e. forms are just complex controls. Thus, controls may contain other controls, which allows displaying e.g. the location of a Person as complex Address control within a Person control. Thus, any level of imbedded controls can be created without defining specific wrapper for complex controls.

The ALM considers controls as class methods, which are member of GUI classes. Thus, an ODABA data type (class) might be specialized to an implementation class and to a GUI class at the same time. Ordering GUI resources in classes and considering them as class methods has the great advantage that controls can be overloaded. ALM supports control overloading in a simplified version. Overloading is not based on inheritance, but on same control names. Defining e.g. a subordinated form control for a tree control, the form control can be marked as virtual, which causes the ALM loading the form control from the GUI class corresponding to the object type of the selected item.

The application above shows an object tree, which has a region for each object type. Data for selected objects is shown on the right side loading a virtual control ( tab_properties in this example). Selecting an item in one of the regions causes the ALM to load the tab_properties control from the GUI class for the object type.

The ALM supports several actions in order to provide support for user specific functions. Actions are defined as abstract actions, i.e. independent form the specific appearance in an application. Thus, an action can be represented as button, as toolbar item, as invisible short cut or as (context) menu item.

Since display states as disabled or hidden apply to the action and not to the GUI element, actions displayed at different places (e.g. in a toolbar and in a menu) will appear in the same way.

A long list of standard actions is provided by the ALM in order to support typical actions as creating or deleting object instances, browsing instances, file dialogs, import/export and other services. Standard or built-in actions are described in "Built-in Actions".

In order to reduce the work burden when building an application, the application logic manager translates data source handle events into GUI actions. In order to do this, the underlying database has to support the following features:

• Supporting data source handler events
• Supporting generic event handles (process events)
• Supporting event optimisation (read transactions)

Data source handler events are generated in order to inform the application that the state of a data source has been changed. Since data sources can be defined in ODABA as simple attributes, object instances and local or global collections, each control in an ADL application is based on an ODABA data source handle (property handle), which submits the required events.

Data events are transformed into GUI actions according to rather simple rules as described below. The required GUI actions for handling data events can be restricted to:

• Instance selected (DBP_Select)
• Instance initialized (DBO_Initialize)
• Instance updated (DBO_Stored, SE_Update, SE_Delete)
• Instance reset (DBO_Reset)
• Instance inserted (DBO_Insered)
• Instance removed (DBO_Removed)
• Collection changed (DBO_Refresh)
• Collection reset (DBO_Reset)
• Collection updated (DBO_Stored, SE_Update, SE_Delete)

The application reacts properly on events fired in the application, i.e. changes caused by the application itself. In order to react on events caused by other applications, two more mechanisms have been provided.

The application manager automatically refreshes data in controls, when it detects a change in the modification count of an instance or collection, which indicates, that another application has updated the instance or collection. This happens always when a control gets focus or a line in a list is selected.

When running in client server mode, server events are sent to the application as well, which allows immediate reactions when an instance or collection changes.

In order to increase the reusability of controls, controls in a form are linked via fields. A form consists of a number of fields, which are linked to appropriate controls. While the control defines the features of the GUI element (style, borders, font, colors, behavior), fields define the data source for the control and the specific appearance in the form (size and position, resize policy, margins, orientation etc.).

Thus, a control can be linked to any number of fields in different forms. This becomes very useful when considering complex controls as sub-forms or lists and trees. But also for standard type controls as single line edit controls for CHAR acter data design will improve, since defaults for the application can be changed simply by changing the control definition ones, only.

Some controls need more than one data source. Thus, a drop list usually requires a data source for the currently selected value and a collection for the list displayed in the list box (base collection or super set). Since the concept of base collections is helpful also in order to associate items to a collection and many other purposes, each field may define a data source for a base collection.

Despite of all the support provided by the ALM, sometimes controls need to define specific behavior. E.g. in order to apply business rules (as validation rules) to a control, the control (still) has to manage the communication between the GUI element and the business component. Specific behavior (application rules) is implemented in GUI context classes. GUI context classes can be linked to fields or controls, but also to projects and applications.

Typically, specific behavior is associated with the control definition. In some cases, it might be useful, however, to overload the control behavior in a field definition referring to the control. When overloading the control behavior by associating a GUI context class with the field, the control behavior will be disabled completely and must be called from the associated field context class when necessary.

Complex controls are "forms", i.e. controls, which have got child controls. The application manager supports defining complex controls (sub-forms), which can be re-used wherever required. Thus, you may define an Address control in order to display address attributes. This can be called in e.g. a Person form and a Company form.

Extensive support has been provided for designing trees and lists. Trees and lists are completely managed by the ALM. The designer just defines the data sources for columns and regions. Since trees and lists support multiple data regions (i.e. one might display in one list or tree Persons and Companies), each tree or list region may consist of any number of data source (region fields) definitions. Similar to fields and controls, regions are defined as region controls referring to columns and sub regions, and as region fields defining the data regions in a tree or list region.

In many cases, designing a tree is done simply by dragging and dropping the data sources to the tree control. The rest is handled by the application manager. This becomes possible, since sub-regions in a tree are referring in many cases to relationships and can, thus, be defined on the base of data model definitions without referring to specific application rules (view definitions).

An action item is a GUI element which visualizes an action. For one action several action items may exist (e.g. as button, tool bar button and menu item). In contrast to the action, an action item defines the appearence of an action, i.e. the text and tool tips to be displayed, the image shown and colors and fonts.

For one action, also several action items might be defined, i.e. defining an action ChangeLanguage , action items German , English , French etc. might be defined in order to call the action with different parameters. In addition to the action name, action items are identified by resource name for the action control or set by the developer. Thus, some functions or properties are provided referring to the action and all related action items.

Since resource names of action controls are unique, the resource name will identify an action, even though it may have got several appearences within a control. Thus, referring to an action via resource name, will savely manage action items for the control. In order to handle all action items referring to an action name, the ActionItems object might be constructed with the action name, only. One may also set the resource name to an empty string after creating the ActionItems object.

In order to manage action items for a resource, get( sName ) might be called with the resource name. In order to manage action items referring to the same action name (regardless of the action type), action items should be constructed with an action name. When identical resource names have been used in order to define reactions for a control, both, action and resource name should be set.

In order to obtain information about actions by position, get( iPosition ) might be called.