Creating a View

The rules for creating a view are actually quite simple. Create a container client. Inside the container object, place all of your data-dictionary objects (DDOs). The DDOs must be placed side by side (as siblings of each other) and properly connected to each other with set ddo_server message. Place your data-entry objects (DEOs) below your DDOs. The DEOs should be nested according to navigational needs. At least one of the DDOs must be assigned to at least one of the DEOs with the set server message, and one of the assigned DDOs should be identified as the view’s main DDO. That's it.

The Container Object

A view must be fully encapsulated. This means that the entire view must be contained inside a single object. The container object should be based on the dbView class. The external program will communicate with this view by sending messages to this dbView object.

Views are activated by sending a special message to the view’s parent object. This message must be created along with the view. A special command, Activate_view (and, optionally, Deferred_view ) is used to create this method. By convention the name of this message should be the name of object, preceded with "activate_" (e.g., the view oCustomer would have an access method of Activate_oCustomer). This might be the only external access method to this object.

The Data-Dictionary Objects

As stated, a view contains a group of connected data-dictionary objects. Before you create the data dictionary objects, you must first create the data-dictionary classes. Using the Database Builder utility you can very easily create data dictionary subclass for each data table in your database. These classes will be based on the DataDictionary class. These classes contain all of your special database rules.

Each data-dictionary subclasses will be placed in its own own package file(s). The conventional file extension for data-dictionary-subclass packages is ".dd". Any component that needs to use a particular data table and the database rules that are represented in its data dictionary class, may simply use the package file that contains it.

A single program will often have multiple views that contain DDOs that access the same data file and therefore are based on the same data-dictionary subclass. Because these DDOs will reside in different views, they are each encapsulated by their respective container object, and no conflict will occur among them, even if they have the same name.

There are explicit rules for placing DDOs in a view client. These are:

When you create and connect DDOs in a view, you are creating a data-dictionary structure. The DDOs will all act in a coordinated fashion—this is what you want. A data-dictionary structure must be encapsulated inside the view. You would never connect two DDOs across two views.

Placing your objects in a view is easy. Care must be taken to make sure that the updating links are properly established. The following diagram provides an example of a database structure, a visual representation of the data-server structure (and linking) and a sample of how this structure is coded.

 

A Typical Database File Structure

 
        
 

Data-Server Structure and Updating Links

 
            
 

Coding the Data-Server Structure

 

Object View_Object is a dbView

 

    Object Customer_DD is a Customer_DataDictionary

    End_Object

 

    Object Terms_DD is a Terms_DataDictionary

    End_Object

 

    Object Vendor_DD is a Vendor_DataDictionary

    End_Object

 

    Object Orders_DD is an Orders_DataDictionary

        set ddo_server to Customer_DD

        set ddo_server to Terms_DD

    End_Object

 

    Object Inventory_DD is an Inventory_DataDictionary

        set ddo_server to Vendor_DD

    End_Object

 

    Object OrderDtl_DD is an OrderDtl_DataDictionary

        set ddo_server to Orders_DD

        set ddo_server to Inventory_DD

        set constrain_file to Orders.File_number

    End_Object

    :

The Data-Entry Objects (DEOs)

Your data-entry objects are placed below your DDOs in the view. The DEOs are created with the following rules:

In some cases, all DEOs will connect to a single DDO (although this DDO will often connect to other DDOs). In other cases, different DEOs within a view will use different DDOs. An order entry view will have its header DEOs using a header DDO and the line-detail DEOs using a detail DDO. In all cases, DEOs only use DDOs that are internal to the current view.

Object Referencing

Although there are several ways to access an object in DataFlex, the Framework is designed to use only one method for referencing an object – you simply refer to the object. This is referred to as the standard object access syntax. For example:

Set Server to Customer_dd

Get Value of oCustomerState to sState

Send UpdateValue of oMyHelper sParam1

Send Message of object_name {param1 .. param_n}

Get  Message of object_name {param_1 .. param_n} to ReturnValue

Set  Message of object_name to ParamValue

Basically, this method says "Find an object named object_name that is a child of the current-object (the current-object is the object sending the message). If the child object is found, the message is sent to this object. If this were all this could do, it would be a limited method for accessing objects. Delegation, however, makes this an extremely powerful object-access method.

If object_name is not found among the children of the current object, the message gets delegated to the current object’s parent object. The parent object then looks for an object named object_name among its child objects. At this point, object_name might be found among siblings of the original current object. If not, delegation occurs again, and the siblings of the parent object are reviewed. Understanding the role delegation plays here is crucial.

Note:

All objects are accessed using the standard object access syntax. This provides access to child objects, sibling objects, and sibling-of-parent objects on up the object tree. Other ways of referencing objects are never used.

If an object cannot be accessed using this access syntax, you should not be accessing it from where you are trying to. For example, a parent object should not directly communicate with a grandchild object. The principle of encapsulation and this access method discourages this. (An exception to this rule, the use of object neighborhoods, will be discussed later.)

Compatibility Note:

Earlier versions of DataFlex required slightly more complex syntax for standard object access where the object name needed to be part of an expression. Examples of this syntax are Send MyMessage of  (oMyObject(self)) and Send MyMessage of (oMyObject(current_object)). This more complicated syntax is not required and can be replaced with the recommended and simpler Send MyMessage of oMyObject.

Constructing a View

This can all be summarized in the following way. An object view consists of a dbView, which encapsulates all DDOs and DEOs. All DDOs are placed as sibling objects inside the container. They are connected to each other with the set DDO_Server message. DEOs are placed underneath the DDOs and are nested (or not nested) according to navigational needs. The DEOs are connected to the data-server structure with the server property. Because views completely encapsulate their DDOs and their DEOs, they are independent stand-alone units. A view can be added to any program without fear of this new view creating side effects in other parts of the program.

A View-Object Package

Views should be created inside their own package files. In addition to the view object, this package should use still other package files and incorporate a view-access method into the view. The following example shows what a simple Studio generated view-object package looks like:

Use dfClient.pkg

Use DataDict.pkg

Use dfEntry.pkg

Use dfCEntry.pkg

Use Vendor.DD

 

DEFERRED_VIEW Activate_oVendorView FOR ;

;

Object oVendorView is a dbView

    Set Border_Style to Border_Thick

    Set Label to "Vendor Entry View"

    Set Location to 6 6

    Set Size to 137 281

    Set piMaxSize to 137 350

    Set piMinSize to 137 215

 

    Object Vendor_DD is a Vendor_DataDictionary

    End_Object    // Vendor_DD

 

    Set Main_DD to Vendor_DD

    Set Server to Vendor_DD

 

    Object oContainer1 is a dbContainer3d

        Set Size to 129 273

        Set Location to 4 4

        Set peAnchors to anAll

        Object oVendor_Id is a dbForm

            Entry_Item Vendor.ID

            Set Label to "Vendor ID:"

            Set Size to 13 42

            Set Location to 4 67

            Set peAnchors to anTopLeft

            Set Label_Col_Offset to 2

            Set Label_Justification_Mode to jMode_Right

        End_Object    // oVendor_ID

 

        Object oVendor_Name is a dbForm

            Entry_Item Vendor.Name

            Set Label to "Vendor Name:"

            Set Size to 13 186

            Set Location to 18 67

            Set peAnchors to anTopLeftRight

            Set Label_Col_Offset to 2

            Set Label_Justification_Mode to jMode_Right

        End_Object    // oVendor_Name

 

        Object oVendor_Address is a dbForm

            Entry_Item Vendor.Address

            Set Label to "Street Address:"

            Set Size to 13 186

            Set Location to 34 67

            Set peAnchors to anTopLeftRight

            Set Label_Col_Offset to 2

            Set Label_Justification_Mode to jMode_Right

        End_Object    // oVendor_Address

 

        Object oVendor_City is a dbForm

            Entry_Item Vendor.City

            Set Label to "City:"

            Set Size to 13 90

            Set Location to 49 67

            Set peAnchors to anTopLeft

            Set Label_Col_Offset to 2

            Set Label_Justification_Mode to jMode_Right

        End_Object    // oVendor_City

 

        Object oVendor_State is a dbComboForm

            Entry_Item Vendor.State

            Set Label to "State:"

            Set Size to 13 32

            Set Location to 64 67

            Set peAnchors to anTopLeft

            Set Form_Border to 0

            Set Label_Col_Offset to 2

            Set Label_Justification_Mode to jMode_Right

            Set Entry_State to False

            Set Code_Display_Mode to cb_code_display_code

        End_Object    // oVendor_State

 

        Object oVendor_Zip is a dbForm

            Entry_Item Vendor.Zip

            Set Label to "Zip/Postal Code:"

            Set Size to 13 66

            Set Location to 79 67

            Set peAnchors to anTopLeft

            Set Label_Col_Offset to 2

            Set Label_Justification_Mode to jMode_Right

        End_Object    // oVendor_Zip

 

        Object oVendor_Phone_Number is a dbForm

            Entry_Item Vendor.Phone_Number

            Set Label to "Phone Number:"

            Set Size to 13 126

            Set Location to 94 67

            Set peAnchors to anTopLeftRight

            Set Label_Col_Offset to 2

            Set Label_Justification_Mode to jMode_Right

        End_Object    // oVendor_Phone_Number

 

        Object oVendor_Fax_Number is a dbForm

            Entry_Item Vendor.Fax_Number

            Set Label to "Fax Number:"

            Set Size to 13 126

            Set Location to 108 67

            Set peAnchors to anTopLeftRight

            Set Label_Col_Offset to 2

            Set Label_Justification_Mode to jMode_Right

        End_Object    // oVendor_Fax_Number

 

    End_Object    // oContainer1

 

CD_End_Object    // oVendorView

 

This is a complete view package. Notable elements are:

 

Next Topic

Lookup Lists