In DataFlex, your application business rules are expressed through and managed by Data Dictionaries. Data Dictionaries create a layer between your application logic and your data. This has the following advantages:
It lets your application interact more effectively with your database – Data Dictionaries provides your application with a wealth of information about your database that is not part of your physical database. It extends your database.
It protects your data – Data Dictionaries make sure that only valid data is added to your database.
It centralizes application logic – All of the information and rules about a Table is stored in a single place. If you need to make a change, you make a change in a single place and all parts of your application acquire the change.
Data Dictionaries are defined as classes. You will create a Data Dictionary class for each table in your database. These classes will be used while you are building your application and when you run your application.
While you are building your application the DataFlex development tools will use the information in your Data Dictionary classes to assist you in the development process. This information is used when you build Windows entry views, Reports and web pages. The Studio and its wizards will use the Data Dictionaries to determine:
What tables should be opened and how they should be connected
What kinds of controls should be used for a particular field (e.g., form, checkbox)
What the labels and context help text should be used for your controls
When lookup lists should be used, how it should be used, and how it will look.
Properly defined Data Dictionaries makes it easy to rapidly create good looking, solid and maintainable applications.
Data Dictionaries are added to an application by creating Data Dictionary Objects (DDOs). At runtime, the DDOs serve two main purposes:
They coordinate database activity among data-entry objects (DEOs)
They provide database validation and update services to a program
These two purposes are distinct.
Creating a structure of DDOs, properly connecting the objects together and properly connecting DEOs to this structure provides coordinated database activity. These connections are all programmed in your components at the object level.
The database rules are maintained and enforced by created in your data dictionary class by setting properties and defining various Data Dictionary events. This is programmed at the class level.
Working with Data Dictionaries consists of:
Creating a data dictionary subclass for each table in your database and coding database rules in these classes. This is done by setting properties and creating functions and procedures.
Creating Data Dictionary Object structures inside of views, web objects and other components. A DDO structure is a group of DD objects that are connected to provide synchronized access to related tables.
Creating objects (data entry objects) or methods (functions / procedures) inside your view, web object or other component that communicates with your DDOs. This allows you to view, create, edit or delete your data.
You will create a Data Dictionary class for each table in your application. These classes, based on the DataDictionary class allow you to define information and set rules for a table. By placing these rules in a single place, a class, you will not have to repeat those rules in every component that accesses the table. The rules you can specify in this class will:
Define the table’s structure
Specify how it connects to other tables
Define what field properties and validations apply
Define what rules should be applied during saves, deletes and updates
Define other helper information such as label names and help text.
All data changes go through your Data Dictionary objects. Before data is changed in your database the Data Dictionaries validate your data using the rules, both simple and complex, that you build in your Data Dictionary classes.
Data Dictionaries are such an important class that a special tool in the Studio, the Data Dictionary Modeler, is provided that allows you to create and maintain Data Dictionary classes visually.
Building classes is discussed in Defining Data Dictionary Classes.
A set of related tables are represented you your application as a Data Dictionary Object (DDO) structure. DDO structures are created within various container objects that are designed to handle DDOs. Some of the container objects supported for this are:
dbView – These are used by windows applications for data entry
ReportView – These are used by windows application for reporting
BusinessProcess – These are used by windows and web applications to handle batch process updates
cWebBusinessProcess – These are used in Web Applications to provide all of the back end support for your Browser HTML pages
cWebService – These are used in Web Applications to provides support for web-services.
The rules for assembling DDO structures are the same for all of these containers. Each Data Dictionary object must be created and properly connected to the structure. This is done through child DDOs creating links to their parent DDOs.
When properly assembled DDO structures provide synchronized access to a full set of hierarchical data. Messages are propagated, as needed, between various Data Dictionary objects providing consistent and proper behaviors for your find, clear, save and delete operations. In additions, these structures are validated as being complete before you are allowed to change data.
The Studio handles the building of DDO structures for you.
Data Dictionary Object Structures is discussed in Creating Data Dictionary Object Structures.
An additional job of Data Dictionary objects is to allow you to constrain and filter records within a component. Two types of constraints are supported:
When one DDO relates to another, you may want the child DDO to only show the records that relate to the current record in the related-to, parent DDO. This is called a relates-to constraint.
A view or report may only be concerned with a subset of records at any one time. You could, for example, specify customers and a given region and/or tax bracket. These are called Filter constraints.
Both of these kinds of constraints (and the can be combined) are defined inside of your DDO structures.
Constraints and Filters are discussed in Constraints and Filters.
The object that contains a DDO structure also contains all of the objects and methods that are used to communicate with those DDOs. This communication process is therefore completely encapsulated.
In some cases, this communication will occur between a data entry object (DEO) and a DDO. For example, a windows view will contain DEOs that allow you to view and edit your data. Each DEO within the view is assigned to a DDO and all communication between the DDO and the DEO are automatic.
In other cases, the communication will occur between a method (a procedure or function) and a DDO. For example, a business process object, a web browser object or a web service object will contain a DDO structure and methods that use the DDO.
In all cases, DDOs are used for the same purpose. They need to be able to:
Find or Clear data
Return information about a DDO field value
Make changes in a DDO’s field value.
Validate and Save data
Validate and Delete data
In a web application, the connection between your DDO and DEO (your browser) is indirect, or batched. All changes in a DDO are sent to the browser in HTML format as a single event. All changes in a DEO (the browser) are sent to the DDO as a single batch submission. Your Web Browser Object coordinates this activity.
The same DDO is capable of supporting different interfaces (e.g., windows controls, HTML pages, web services) and therefore the DDO's ability to interface with these interfaces will differ. However, the basic DDO logic and validation services are supported properly across all platforms. For example, field validations are always properly executed before a save.
Using Data Dictionary Objects is discussed in Using Data Dictionary Objects in your Components.
Windows applications contain a special kind of entry object that it closely integrated with Data Dictionary Objects. These are called data-entry objects (DEOs). Each DEO is bound to a Field in a table. In addition, each DEO specifies a Data Dictionary object to act as its server.
A windows view will consist of a DDO structure and a number of these DEOs. Messages, often triggered by user interaction, are sent from the DEO to its server DDO. The messages tell the DDO to perform one of the DDO tasks listed above (find, save, delete, etc.). When the DDO has completed the requested operation it will send notification messages to all of the connected DEOs. The DEOs will use these notifications to update their data and appearance. The synchronization between DEOs and DDOs allows these entry objects to be fully “data-aware”. By adding very little code, you can create sophisticated data entry applications.
Windows applications can also use DDOs within reports. A report will define a DDO to act as its server. All record finding will be handled automatically by messages sent from the report to the server DDO. The use of DDOs in reports is not required.
Windows applications also use batch process objects to handle custom updates. A Batch Process object must contain custom methods that perform the processes. You create the code in these methods that controls the activity between your DDO and the process. A complete Data Dictionary interface exists that allows you write code to perform the same kinds of tasks that the DEOs do for you automatically (e.g. clear, find, change data, save, delete).
Web Applications use web objects to handle all processing. There are two types of web-objects:
Web Browser Objects (cWebBusinessProcess) – these are used to interact with browser based web-pages
Web Service Objects (cWebService) – these are used to provide web-services.
These objects are designed to contain DDO structures and methods that communicate with those DDOs. A developer interacts with the DDOs in the same manner they operate with batch processes in a windows application.
Web Browser Objects expect that the visual interface is provided by creating HTML pages. Those pages are created (programmed) using Active Server Pages (ASP). The ASP pages make calls into Web-Browser objects. Within the Web-Browser object you create methods to do whatever is needed. You then make this method available to your ASP page by publishing its the interface. In addition, Web-Browser objects contain a number of built-in interfaces that provide high-level access your Data Dictionaries. This allows you to perform all of the basic Data Dictionary functions (e.g., Find, Clear, Save, Delete) without having to write any code in your Web Browser Objects.
Web Service Objects provide web-service support. A web-service may or may not need to access Data Dictionaries. If they do, a DDO structure may be added to the Web-Service object and methods can be created that will communicate with the DDOs as needed.