Terms:
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…
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.
Test!
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.
Test!
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:
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.
Test!
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.
Test!
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
End_Object
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
End_Procedure
Procedure FindByRowID Integer iFile RowID riRowIDIf ((iFile = Customer.File_Number) and (Current_Record(Self))) Procedure_Return
Forward Send Request_Find iMode iFile iIndex
End_Procedure
If ((iFile = Customer.File_Number) and (Current_Record(Self))) Procedure_Return
Forward Send FindByRowID iFile riRowID
End_Procedure
End_Object
Test!
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.
No comments:
Post a Comment