The new system form
Data Classes is used to create data classes.
In this form you create data classes almost in the same way like entities in the Entity form. The mapping into the database is performed by Create Database Object and can be realised as table or as a view. A table/view name does not have to be explicitly assigned.
If you modify an existing data class, you only have to change it in the data base with the help of Create Database Object if you altered field assignments, associations or Where conditions. In case of modifications of trigger functions or method calls this is not necessary.
Fields for data classes are created just like for classical model objects in the sub-list Field Assignment. Depending on the display type (table/view) the sub list either displays a complete or a view-specific field attribute record. Additionally, the Sorting (database sorting) can be specified, which used to be a mask-field attribute.
Associations between data classes as a term replace the classical model objects DataView relations and links. Implementation and creation in the association sub-lists, however, correspond to the old link. As opposed to links, in the entity form you must take care of the direction of an association.
If you want to create associations between classes which are mapped in the database as DataView tables or point to such, you can additionally select the DataView-internal C_ID-fields as key fields in Key-1/Key-2.
The separation of data-and presentation-level resulted in the introduction of a new trigger concept. While searching/editing of data in the database used to be initiated at mask triggers (usually at Action triggers) -- which means objects on the presentation level -- now triggers for data classes -- which means on data level -- have been introduced, which realize this function. The name of these triggers is ON-trigger and they can be selected within the sub-list Trigger in the field Name. The corresponding trigger functions are stored in the field Function Code. You can enter your own C++ userexits.
ON-triggers are compact triggers. For instance the ON-DATACHANGE trigger replaces the functional sequence Pre_Field-Trigger -> update field content-> Post_Field-Trigger or the ON-UPDATE-Trigger replaces the sequence Pre_Action-Trigger -> saving in database -> Post_Action-Trigger by only one trigger, respectively. If no data class-specific trigger function has been defined, a trigger-specific default action (CalDef) will be executed. It can be compared to the action between Pre_ and Post_Fiel-Trigger or Pre_ and Post_Action-Trigger, respectively. If a trigger function has been defined, you have to call the default action within this function. Which action is executed in the function before or after the default action or whether the default action is called at all, must be implemented or checked by you in the trigger function itself. Return codes of trigger functions have no meaning any longer, because you can influence the run time behaviour of DataView within the trigger function itself.
The picture compares the workings for an Update at the Pre_/Post-Action-Trigger and at the ON-UPDATE-Trigger
Methods for data classes are C++ userexits which are called by the program. For instance you could design a default method for the release of materials for the Material data class.
Methods can -- similar to the call of NoSelect or Select functions -- be executed both for all objects (records) of the class and for individual objects. The specification is done in the Type field.
In order to call methods via the interface objects (menus, buttons) which are still to be designed, the fields Sequence, Title, and Tooltip already exist. Any attributes entered there could later be inherited for instance to a menu item.
Class methods can be inherited to derived classes and behave in a polymorph way.
A data class can be derived from one or several other data classes (basic classes). In DataView this derivation is always performed via arguments. For instance if you create a data class 1 and map this as a view in the database, its fields will usually point to one or several basic tables. If these basic tables are maps of other data classes 2, 3, ..., exactly those will become basic classes of data class 1. The following rules apply:
Derived data classes can inherit associations and methods from these basic classes. This means in detail:
For instance in a class Screws derived from a general Material data class you could define an own method (with the same name) for releasing screws, which overrides the default release method defined for materials.
For instance a 1:n association between materials and producers can also be used in a derived class Screws.
If ON-triggers are defined for derived data classes, the class-specific trigger functions will be activated before the trigger functions of the corresponding basic class when the derived class is addressed.
The Where-condition is a part of the view-definition of a derived data class. The condition is automatically activated at each query to the view.
The structure of a view-condition is not limited by DataView. When you design it you have to care for a useful data selection yourself. For instance, if several linked basic tables are included you have to incorporate all required key fields. The condition is to be formulated using SQL syntax and is stored in the database unchecked when the view is created. Because the syntax depends on the database connected, the form contains two condition fields, SQL-Statement/ORACLE and SQL-Statement/SQL-Server.
For a derived data class with several basic classes you can automatically create a default Where-condition. It is a precondition that the basic classes are linked via associations in some way. DataView will then inspect the key fields defined there and create a default condition, which creates an expression in the form: TABLENAME1.COLUMNNAME1=TABLENAME2.COLUMNNAME2 for each link. If there are several links, the expressions will be automatically combined with AND.