Context classes

In ODABA, business and application rules are implemented in so-called context classes. Context programming is provided for two reasons: One reason is, that this is a flexible way of associating context specific behavior for database and GUI resources. By associating context classes development resources, behavior becomes independent and may work properly for several resources.

The second reason is, that this event handlers implemented in context classes are the most efficient way of handling database and GUI events whenever necessary.

Usually, only a few percent of development resources need to be linked with specific context classes, since many database and GUI framework rules directly react on data changes and changes in property handle state. In order to implement a context class, the following steps become necessary:

• Create a resource reference (SDB_ResourceRef) for the development resource (e.g in Designer or ClassEditor), which provides the link between resource and the context class
• Create or associate the context class to be linked with the created resource reference
• Implement event handlers and other application rules in the context class
• [Create the context library]

Context classes might be implemented or updated directly from within the Designer clicking the Context classes tab on bottom of the work area. More comfortable it is implementing context classes in the ClassEditor (database or GUI context class project), But one may also implement context classes in any other development environment. The only interface between the context class library and the GUI resource is the resource number (C++) or the class name assigned to the resource reference (C# and OSI).

One may mix C++ or C# context classes with OSI context classes, but not C# and C++ context classes, i.e. one has to decide whether the interface is implemented in C++/OSI or C#/OSI. One might also mix C++ or C# and OSI context functions in one context class. In this case, the context class should be defined with programming language C++ or C#, but not as OSI.

This documents describes the necessary steps for creating a context class without using ClassEditor. This is not so simple and one may also use the ClassEditor, which automatically does many things to be done manually otherwise. Hence, the subsequent topics will also describe the actions to the performed using the ClassEditor for implementing context classes.

GUI framework and database support different types of context classes as described below.

Database context programming allows defining business rules for different database model resources. A database context class provide event handlers and common application rules for database model resources defined in the ClassEditor or any other environment (property, data type, object space, database). Database context classes inherit from odaba::DBBaseContext.

The context class receives database and property handle events generated by the database system. Database ebents are a consequence from changes in the ODABA database. Property handle events inform about state changes in a property handle (e.g. when changing the selection in a property handle). Typically, context classes are implemented for complex data type definitions (odaba::TypeContext) or properties of a complex data type (odaba::PropertyContext). While TypeContext classes mainly handle instance events, PropertyContext classes allow handling collection events.

All database context classes inherit from odaba::DBBaseContext. The DBBaseContext context class defines all handler functions, which may be overloaded in database context classes. BesidesTypeContext and PropertyContext classes, some more specific context classes are available for database and object space resources.

The database context class (DatabaseContext) is typically implemented in order to react on database open events, Thus, one may provide specific user login procedures, initializing database or application options, opening additional files or databases or other actions.

The database specific context class inherits from DatabaseContext and has to be associated with the database resource (SDB_Database).

In case of using several object spaces in a database, each object space may obtain a different context (ObjectSpaceContext). Object space context classes may apply on the root object space, in which case it has to be associated to the root object space definition in the database resource (SDB_Database).

Object space context classes for the root object space become also necessary, when opening several object spaces for the same database. Since the object space is the lowest thread save database access unit, object spaces are used when running databases in multi-thread environments. In order to perform special initialization actions, an object space context class has to be implemented rather than a database context class, which will be called only once, when opening the database.

In order to define object space context classes for specific object spaces, one has to define named objects (SDB_NamedObject) in the dictionary or resource database, that are used for creating an object space later in the database (schema object space). It is not possible to assign context classes to ad-hoc object spaces.

Data type context classes (TypeContext) may be assigned to complex data type definitions in the data model. Type context classes are typically used for handling instance events (e.g. calculating transient attributes when reading an instance or selecting proper language for generic attributes).

Type context classes cannot be provided for built-in data types or enumerations, which are considered as values, but for complex data types, only. Events for built-in type enumerator values are handled by property context classes.

Property context classes (PropertyContext) allow reacting on collection events and on built-in or enumeration type value events. Thus, one may handle insert or remove events for a collection, but also update events for a number (or other built-in type instance) or enumerator values.

Context programming for the GUI framework allows defining application rules for different application resources. A GUI context class provide event handlers and common application rules for a GUI resource defined in the Designer. (field/field control, project, application). Most GUI context classes inherit from ControlContext, which might be associated with a field (ADK_Field) or field control (ADK_FieldControl).

The context class receives GUI or Data events generated by the GUI framework. Data ebents are a consequence from ODABA database events, which are translated into application data events. GUI events inform about several events caused by actions on the user interface. Since database events as selecting an instance in property handle (control data source) are turned in GUI actions (e.g. selecting the selected instance in a list control), which, again will fire appropriate GUI events. Usually, GUI context classes handle GUI events, but sometimes it becomes necessary to react on data events as vell, e.g. in order to prevent the GUI reacting on changing selection in a data source (property handle).

All GUI context classes inherit from odabagui::GUIBaseContext. The GUIBaseContext context class defines all handler functions, which may be overloaded in GUI context classes. Besides the odabagui::ControlContext context class, some more specific context classes are available for project and application resources.

The project context class is typically implemented in order to react on application start-up events, Thus, one may provide specific user login dialogs, initializing application options, opening additional files or databases or other actions. On the other side, the project context (ProjectContext) inherits from the ControlContext class and provides all the features supported by control context classes.

The application specific project context class inherits from ProjectContext and has to be associated with the project resource (or the main window resource referenced in the project).

In case of multiple application projects, each application may get a separate application context in order to initialize different applications differently.

The control context class provides generic support for any kind of control. Most events and standard actions are supported supported for all control types, but there are always events, that only happen e.g. for list controls but never for line edit controls. Same is true for a number of standard actions, which make sense in a certain context, only. Standard actions supported for specific control types are described in the control type reference section (Control style reference) of this manual.

Control context classes inherit from ControlContext and might be linked to field resources (ADK_Field) or field control resources (ADK_FieldControl). Assigning a context class to a field control is more general, since is this case the context class is active for any form, teat refers to the field control. Assigning a context class to a field, which is exclusive part of another control or form, the context class is in effect only for the field in the given context. When the field refers to a field control assigned with another context class, the field context class is used rather than the field control context class. Each context class might me linked with any number of fields and/or field controls.