Examples of org.openbp.core.model.item.type.DataMemberImpl

OpenBP data type member definition object. A member definition object (or short memberdef) describes an member of a OpenBP data type ( {@link DataTypeItem}). The name of the member must follow Java naming conventions and must begin with an uppercase letter. Actually, DataMember would not have to implement DisplayObject, DescriptionObject would do because data type members usually don't need to be displayed in an editor workspace in a special manner.
However, we use the display name for form generation and error message output when the automatic form validation fails.
Note that DescriptionObject/DisplayObject currently do not support localization. This should be added soon. A data member can have either a simple type or a complex type. Simple types represent actual values whereas complex types always represent references to complex objects.

References

A member can optionally refer to another object. There are two types of references:

A link reference references exactly one object (or no object if the link is empty).
This implements a 1:0..1 relation.
The type of the member that holds the reference is always a complex data type. The type either matches the data type of the object to be referenced or is a base class of the referenced object.
A collection reference references a set of objects (or no object if the collection is empty). This implements a 1:0..n relation.
The member that holds the references must be defined as collection member. The member type must always be a complex data type. The type either matches the data type of the objects to be referenced or is a base class of the referenced objects.

Database reference processing

References can be automatically resolved by the system when an object is read from the data base.
However, you must define how the objects are related.
Suppose we have the following two data types defined, which map to database tables: @code 3Type Company Database Table COMPANY Member CompanyName - Type: String - Database Field: CO_NAME - Database Type: VARCHAR Member CompanyId - Type: Integer - Database Field: CO_ID - Database Type: INTEGER Type Employee Database Table EMPLOYEE Member FullName - Type: String - Database Field: EMP_FULL_NAME - Database Type: VARCHAR Member EmployeeId - Type: Integer - Database Field: EMP_ID - Database Type: INTEGER Member EmployingCompanyId - Type: Integer - Database Field: EMP_CO_ID - Database Type: INTEGER @code A company can have an arbitrary number of employees. We have a 1:0..n relationsship between the Company and the Employee type. If you select a company, you also automatically want the employees of the company to be selected and linked with the selected company.
In order to achieve this behavior, you would extend the Company datatype by adding an additional collection field and defining the relation to the objects it should contain: @code 3Type Company ... Member Employees - Type Employee - Reference Member: CompanyId - Foreign Member: Employee.EmployingCompanyId - Autoload Count: -1 @code When a company is retrieved from the database, an additional select operation will be executed using the following statement:
@code 3select * from Employee where EMP_CO_ID = $CompanyId @code You may also specify an order clause for the reference, which will be considered when selecting the referenced entities. The results of this select operation will be stored in the Employees collection member. You may access the collection for example in a visual as loop variable (e. g. for Velocity "$Company.Employees") in order to display all records. A good idea is to copy the code for the record display from a generated browser form (in our example the Employee Browser). Note that only the List, Vector, Array and Iterator collection types are supported for database operations. Note that references are supported for select operations only. Insert, update and delete operations do not account for references (however, this may depend on the underlying database layer in the future). \i\bTip:\i\b You might want the Company object retrieve its employees only in certain situations (e. g. for regular company maintenance it is not required to have all the employees retrieved). However, in those cases where you need the employees, you want them retrieved automatically.
To solve this problem, define a regular Company data type w/o the collection member. In addition, define an Object CompanyWithEmployees that has the Company type as its base type (i. e. extends Company) and defines the collection member. @author Heiko Erhardt