A Reference Guide of DDO Technology
– Visual DataFlex–
Outline Mode:
- Introduction
- Terms
- What is a DDO?
- What is a DD Class?
- What is a DDO Tree?
Introduction:
Based on DAF Methodology, the DDO Technology in Visual DataFlex is a study of instantiation, delegation, and polymorphism.
Terms:
Instantiation: The act of creating an object based on a class and class hierarchy.
Delegation: Visual DataFlex features natural full delegation of methods by default, where the method travels first to the object, then to it’s superclass, and on throughout the full class hierarchy until the method is resolved. A method runs to completion without augmentation or definition on the object level but such augmentation, forwarding, or canceling is supported on both the class and object level.
Polymorphism: The act of an object to produce different behavior depending on it’s context.
What is a DDO?
“data dictionary objects” are instantiated in each data entry (or other type) module for the purpose of:
- Providing a “server” for find/clear/save/delete and validation operations for a data table.
- Providing data aware controls with attributes such as capslock, valid values, default values, range definition, selection list definition, etc.
- Communicating with other DDO’s in tandem to do all of the above with coordination.
- Definition of “constraint data filters” where your data can be a subset of the whole.
Sample Object Code:
// doc: instantiation of customer_datadictionary class placed inside panel of data entry form.
Object oCustomer_DD is a Customer_DataDictionary // instantiation of class.
Set DDO_Server to oSalesRep_DD // parent or “server” ddo
Set DDO_Server to oTerms_DD // parent or “server” ddo
Procedure OnConstrain // predefined method
Forward Send OnConstrain // continue delegation
Constrain Customer.Active EQ “Y”
Constrain Customer As (Customer.TotalOwed What is a DD Class?
A data dictionary class is a number of things: about 10 major functions with more omitted for space constraints in this article.
– Visual DataFlex–
Outline Mode:
- Introduction
- Terms
- What is a DDO?
- What is a DD Class?
- What is a DDO Tree?
Introduction:
Based on DAF Methodology, the DDO Technology in Visual DataFlex is a study of instantiation, delegation, and polymorphism.
Terms:
Instantiation: The act of creating an object based on a class and class hierarchy.
Delegation: Visual DataFlex features natural full delegation of methods by default, where the method travels first to the object, then to it’s superclass, and on throughout the full class hierarchy until the method is resolved. A method runs to completion without augmentation or definition on the object level but such augmentation, forwarding, or canceling is supported on both the class and object level.
Polymorphism: The act of an object to produce different behavior depending on it’s context.
What is a DDO?
“data dictionary objects” are instantiated in each data entry (or other type) module for the purpose of:
- Providing a “server” for find/clear/save/delete and validation operations for a data table.
- Providing data aware controls with attributes such as capslock, valid values, default values, range definition, selection list definition, etc.
- Communicating with other DDO’s in tandem to do all of the above with coordination.
- Definition of “constraint data filters” where your data can be a subset of the whole.
Sample Object Code:
// doc: instantiation of customer_datadictionary class placed inside panel of data entry form.
Object oCustomer_DD is a Customer_DataDictionary // instantiation of class.
Set DDO_Server to oSalesRep_DD // parent or “server” ddo
Set DDO_Server to oTerms_DD // parent or “server” ddo
Procedure OnConstrain // predefined method
Forward Send OnConstrain // continue delegation
Constrain Customer.Active EQ “Y”
Constrain Customer As (Customer.TotalOwed What is a DD Class?
A data dictionary class is a number of things: about 10 major functions with more omitted for space constraints in this article.
[1] A Data Dictionary Class defines the attributes for the data table to be communicated to the data aware controls tied into that database table. Attributes include “capslock”, “required entry in this column”, “auto-find upon exit”, “shadowed/non-enterable”, etc.
[2] The DD Class sets the (above noted) attributes differently depending on whether the ddo (instantiated object based on the class) is the direct server of operations, or a parent ddo of the operations server. This creates polymorphism on the object level and allows parent records to be found, required to be found, but not allow changes, for instance.
[3] The DD Class defines which other database table objects must be instantiated alongside with it to perform save and delete operations. For instance, the save of a sales order lineitem would require a dd object (ddo) for the product it was related to in order to reduce inventory or create a backorder. In another instance, the sales order header would require a ddo for the sales order lineitem to be present in order to delete the related order lineitems. Also, a DD Class may be configured to not allow deletes if child records exist.
[4] The DD Class allows columns to be associated with a “selection list” or lookup object. The chosen selection list will create a lookup button on the control chosen for that column and automatically popup and communicate two ways with the selection list.
[5] The DD Class allows the database programmer to define the object labels for each column and also to default the creation of controls for this column to a certain type such as a spinform or comboform, etc. (communication with the visual dataflex studio).
[6] The DD Class features augmentable save, find, clear, delete, and validate methods. The operations server (ddo) in a form or “view” will initiate a cascade of messages designed to perform an operation such as a save operation. When this save occurs, it cascades to all the connected data dictionary objects in the form or “view” which then delegates to the DD Class where you can augment the operation based on business rules you define and business rule exceptions which can be controlled via various means, usually with a property setting.
[7] The DD Class allows the setting of “valid values” validation tables which accompany a column in whatever control form it takes (regular form, comboform, or in a grid). The DD Class can define a list such as “activeinactive” for itself, or share a validation table with other DD Classes such as a list of US states or valid shipping terms.
[8] The DD Class allows for the definition of entry and exit methods for each column of the database table. Whether the column, in data entry, is represented in a comboform, or in a grid, the entry and exit methods follow it.
[9] The DD Class allows for auto-incrementing from a “system file” for ID fields, for instance or lineitem numbers.
[10] The DD Class communicates when instantiated, to validate the find/clear/save/delete cascade of messages along with whatever other ddo objects it is connected to.
What is a DDO Tree?
Data Dictionary Objects are run in tandem to find/clear/save/delete and validate these operations.
Let’s take a sales order entry application for example. The business rules given to you are;
· Customers who are not active may not purchase.
· Active customers may not go over their credit limit by more than 10%.
· Sales orders update the customer total owed.
· Lineitems update both the sales order total and reduce product from inventory.
· Product records update vendor purchase history.
· Sales orders update the salesrep volume sold.
Here’s a sales order entry application ddo tree (simplistic) example:
// doc: ddo tree for SO application
Object oTerms_DD is a Terms_DataDictionary
End_Object
Object oSalesRep_DD
End_Object
Object oCustomer_DD is a Customer_DataDictionary
Set DDO_Server to oSalesRep_DD
Set DDO_Server to oTerms_DD
Procedure OnConstrain
Forward Send OnConstrain
Constrain Customer.Active EQ “Y”
End_Procedure
Function Validate_Save Returns Integer
Integer iReturnVal
Forward Get Validate_Save to iReturnVal
If (Customer.Owed > (Customer.CreditLimit * 1.10)) Error 999 “Customer Over Credit Limit”
Function_Return iReturnVal
End_Function
End_Object
Object oVendor_DD is a Vendor_DataDictionary
End_Object
Object oProduct_DD is a Product_DataDictionary
Set DDO_Server to oVendor_DD
Procedure Update
Forward Send Update
Add (Product.Qty * Product.Price) to Vendor.Volume
End_Procedure
Procedure Backout
Forward Send Backout
Subtract (Product.Qty * Product.Price) from Vendor.Volume
End_Procedure
End_Object
Object oSaleHead is a SaleHead_DataDictionary
Set DDO_Server to oCustomerDD
Procedure Update
Forward Send Update
Add SaleHead.Total to Customer.Owed
Add SaleHead.Total to SalesRep.Volume
End_Procedure
Procedure Backout
Forward Send Backout
Subtract SaleHead.Total from Customer.Owed
Subtract SaleHead.Total from SalesRep.Volume
End_Procedure
End_Object
Object oLineItem_DD is a LineItem_DataDictionary
Set DDO_Server to oSaleHead_DD
Set DDO_Server to oProduct_DD
Procedure Update
Forward Send Update
Add LineItem.Total to SaleHead.Total
Subtract LineItem.Qty from Product.QtyOnHand
End_Procedure
Procedure Backout
Forward Send Backout
Subtract LineItem.Total from SaleHead.Total
Add LineItem.Qty to Product.QtyOnHand
End_Procedure
End_Object
// END CODE
With a pictorial version of what’s happening in the tree:
[3] The DD Class defines which other database table objects must be instantiated alongside with it to perform save and delete operations. For instance, the save of a sales order lineitem would require a dd object (ddo) for the product it was related to in order to reduce inventory or create a backorder. In another instance, the sales order header would require a ddo for the sales order lineitem to be present in order to delete the related order lineitems. Also, a DD Class may be configured to not allow deletes if child records exist.
[4] The DD Class allows columns to be associated with a “selection list” or lookup object. The chosen selection list will create a lookup button on the control chosen for that column and automatically popup and communicate two ways with the selection list.
[5] The DD Class allows the database programmer to define the object labels for each column and also to default the creation of controls for this column to a certain type such as a spinform or comboform, etc. (communication with the visual dataflex studio).
[6] The DD Class features augmentable save, find, clear, delete, and validate methods. The operations server (ddo) in a form or “view” will initiate a cascade of messages designed to perform an operation such as a save operation. When this save occurs, it cascades to all the connected data dictionary objects in the form or “view” which then delegates to the DD Class where you can augment the operation based on business rules you define and business rule exceptions which can be controlled via various means, usually with a property setting.
[7] The DD Class allows the setting of “valid values” validation tables which accompany a column in whatever control form it takes (regular form, comboform, or in a grid). The DD Class can define a list such as “activeinactive” for itself, or share a validation table with other DD Classes such as a list of US states or valid shipping terms.
[8] The DD Class allows for the definition of entry and exit methods for each column of the database table. Whether the column, in data entry, is represented in a comboform, or in a grid, the entry and exit methods follow it.
[9] The DD Class allows for auto-incrementing from a “system file” for ID fields, for instance or lineitem numbers.
[10] The DD Class communicates when instantiated, to validate the find/clear/save/delete cascade of messages along with whatever other ddo objects it is connected to.
What is a DDO Tree?
Data Dictionary Objects are run in tandem to find/clear/save/delete and validate these operations.
Let’s take a sales order entry application for example. The business rules given to you are;
· Customers who are not active may not purchase.
· Active customers may not go over their credit limit by more than 10%.
· Sales orders update the customer total owed.
· Lineitems update both the sales order total and reduce product from inventory.
· Product records update vendor purchase history.
· Sales orders update the salesrep volume sold.
Here’s a sales order entry application ddo tree (simplistic) example:
// doc: ddo tree for SO application
Object oTerms_DD is a Terms_DataDictionary
End_Object
Object oSalesRep_DD
End_Object
Object oCustomer_DD is a Customer_DataDictionary
Set DDO_Server to oSalesRep_DD
Set DDO_Server to oTerms_DD
Procedure OnConstrain
Forward Send OnConstrain
Constrain Customer.Active EQ “Y”
End_Procedure
Function Validate_Save Returns Integer
Integer iReturnVal
Forward Get Validate_Save to iReturnVal
If (Customer.Owed > (Customer.CreditLimit * 1.10)) Error 999 “Customer Over Credit Limit”
Function_Return iReturnVal
End_Function
End_Object
Object oVendor_DD is a Vendor_DataDictionary
End_Object
Object oProduct_DD is a Product_DataDictionary
Set DDO_Server to oVendor_DD
Procedure Update
Forward Send Update
Add (Product.Qty * Product.Price) to Vendor.Volume
End_Procedure
Procedure Backout
Forward Send Backout
Subtract (Product.Qty * Product.Price) from Vendor.Volume
End_Procedure
End_Object
Object oSaleHead is a SaleHead_DataDictionary
Set DDO_Server to oCustomerDD
Procedure Update
Forward Send Update
Add SaleHead.Total to Customer.Owed
Add SaleHead.Total to SalesRep.Volume
End_Procedure
Procedure Backout
Forward Send Backout
Subtract SaleHead.Total from Customer.Owed
Subtract SaleHead.Total from SalesRep.Volume
End_Procedure
End_Object
Object oLineItem_DD is a LineItem_DataDictionary
Set DDO_Server to oSaleHead_DD
Set DDO_Server to oProduct_DD
Procedure Update
Forward Send Update
Add LineItem.Total to SaleHead.Total
Subtract LineItem.Qty from Product.QtyOnHand
End_Procedure
Procedure Backout
Forward Send Backout
Subtract LineItem.Total from SaleHead.Total
Add LineItem.Qty to Product.QtyOnHand
End_Procedure
End_Object
// END CODE
With a pictorial version of what’s happening in the tree:
No comments:
Post a Comment