Tuesday, October 09, 2007

DDO Tree Technology – DAF Methodology

DDO Tree: A combination of instantiated data dictionary objects tied together.
DAF Methodology: How the ddo tree handles find, clear, save, delete and validation.

Here’s a sample (simple) ddo tree as found in a sales order data entry program or other module…

“Knowing how the ddo tree handles user requests is at least important to know as how to model a data dictionary class”

Communication between the ddo tree and the objects in play is a two way street!

In this example of data entry, the Server of the main panel is Salehead and it controls the find/clear/save/delete and validation of itself and all it’s parent ddo objects.

In a lesson in polymorphism, the “Customer” ddo recognizes it is a parent object of the server in play, and enforces different rules (find required on record for instance) than it normally would if it was the server itself.

Further, the SaleHead ddo takes responsibility for accepting the find/clear/save/delete messages sent via the user. When the cursor/focus is in the customer name window, for instance, the request_find message actually goes directly to the SaleHead ddo, not the Customer ddo. The SaleHead realizes that the message is directed at a parent ddo and forwards the message up thru the connection to the Customer ddo to handle.

Take your data entry module with parents and put a hook message inside the server and the parent “request_find” method and see which pops up first!

In the same way that this communicates upwards, it also communicates downwards so that when a delete message comes to the server, it travels downwards, deleting all children of the server and then itself. The beauty of the methodology is that no parent records can be deleted by the user unless programmatically allowed by the software engineer.

Take any data entry module, place the focus in a parent object cell or window, and press delete. What get’s deleted? Not the parent!

So, augmentation of ALL find/clear/save/delete requests can be done at the server level! Here’s how to code so the customer of an order cannot be changed:

Object Customer_DD is a Customer_DataDictionary

Object SaleHead_DD is a SaleHead_DataDictionary
Set ddo_server to Customer_DD
Procedure Request_Find Integer iMode Integer iFile Integer iIndex
If ((iFile = Customer.File_Number) and (Current_Record(Self))) Procedure_Return
Forward Send Request_Find iMode iFile iIndex
Procedure FindByRowID Integer iFile RowID riRowID
If ((iFile = Customer.File_Number) and (Current_Record(Self))) Procedure_Return
Forward Send FindByRowID iFile riRowID


This is one correct way to code a sales order so the parent cannot be changed of an existing sales order!

So, what have we learned? DAF Methodology.
It’s a study of communication between data entry objects which delegate user messages to the server, and how that server communicates the messages to it’s parent and child tables.

Wednesday, October 03, 2007

Visual DataFlex DDO Tree Technology Reference

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?

Based on DAF Methodology, the DDO Technology in Visual DataFlex is a study of instantiation, delegation, and polymorphism.

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

Object oSalesRep_DD

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”
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

Object oVendor_DD is a Vendor_DataDictionary

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
Procedure Backout
Forward Send Backout
Subtract (Product.Qty * Product.Price) from Vendor.Volume

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
Procedure Backout
Forward Send Backout
Subtract SaleHead.Total from Customer.Owed
Subtract SaleHead.Total from SalesRep.Volume

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
Procedure Backout
Forward Send Backout
Subtract LineItem.Total from SaleHead.Total
Add LineItem.Qty to Product.QtyOnHand

With a pictorial version of what’s happening in the tree: