|
Building a Clarion Data Dictionary
The first step in building the a Clarion application is to construct the Data Dictionary. Thereafter, subsequent applications can reference the same dictionary, or other dictionaries.
The Clarion developer starts the development environment, and selects the File > New > Dictionary command from the menu. In the standard dialog, the developer provides the Dictionary filename, and we begin with a blank dictionary.
Assuming a database already exists, the developer issues the File > Import Table command, or if using the Clarion Enterprise Edition selects either "Synchronize" which imports either the entire database or a subset. A driver list displays available drivers such as Oracle, Pervasive.Sql, ODBC, and a selection of PC flat file databases. For this example, the developer chooses Pervasive.SQL.
Depending on the database driver, the dialog requesting the server and database to connect to will vary. Following this, a dialog showing available tables and views appears.
Clarion Enterprise Edition varies from Clarion Professional Edition in that it contains a Dictionary Synchronizer, which makes it possible to import an entire database in one operation. The synchronizer can also perform additional tasks tasks such as creating Alter Table statements to reflect the table modifications. This document will concentrate on the “basic” tasks, i.e., importing the tables one at a time, to best show the basic procedures.
Once the developer has selected the table, the File Properties dialog appears, allowing the developer to pertinent table properties. Additionally, there is a Comments area, which can be used to generate documentation.
After pressing OK, the developer can then access the specific columns and keys to specify business rules and filed level controls.
For example, the illustration below shows an option set for the CreditLimit column specifying that the column will only accept a value between 0.00 and 999,999.99. The developer can specify client-side data validation rules, and combine these with server side validation.
Similarly, the developer can enter a list of choices for the Region column, in this example we specify (Northern | Eastern | Southern | Western), and the Dictionary will automatically create a Radio button structure that forces the the end user to set the value to one of those four choices. The values property indicate the values to store into the record corresponding to the choice selected, in this case they are the same but could have been numeric or some other value.
As long as the developer uses the default control, the end-user is is forced to comply with that constraint. We should note here that because Clarion compiles to a machine code executable, there is no discernible speed or size penalty within the executable for setting these behaviors in the client rather than in the server.
Additionally, the application can also contain code to provide lookup selections from related tables. If the developer indicates that a value must be one contained in a related table, the Application Generator can automatically include a select button to help the end user choose a value from that table, and the application will automatically reject any value entered that is not present in the other table.
The Dictionary also stores additional user interface attributes, such as the text that should appear in the prompt for any edit box or control referencing the field, including an accelerator key for keyboard focus. It also allows the developer to specify a title for the column to appear in the reports the Application Generator will lay out.
A full range of preformatting options, such as font, style, color, size, numeric formatting, string alignment, string case and more are provided for all the different types of controls.
The Key Properties dialogs allow the developer to specify sort orders for the selected table. When the Application Generator creates a browse window (an intelligent data grid), it will create tabs corresponding to the keys for that table. When the user clicks a tab, the list box with the browse will display the data sorted to reflect the key choice.
The Key Properties also allow the developer to specify auto-number behaviors, if not implemented in the database.
Within the scope of this exercise, we import three other tables to illustrate how the Application Generator determines a structure for the default application. The table names we import are Artists, Categories, and Tracks. The Dictionary also stores information about the relationships between tables, and can even specify that the application manage referential integrity. In the illustration below, the developer specifies that the server will manage the relational integrity (RI) code for the Category ID, a primary key in the Categories table and the same column, a foreign key, in the Discs table.
In fact, the developer can go into the column properties -->validity property, to specify that the category in the Discs table must be a value found in the Categories table. This automatically creates a default dropdown list for the end-user based on the existing values for category in the Categories table.
In general, Clarion developers spend a good amount of time working with the metadata attributes in the Dictionary. In practice, this saves many, many hours of time when creating applications.
When creating applications, the developer selects the tables that the application should access, and the business rules, behaviors, and formatting options will be generated based on the Dictionary metadata.
Clarion Enterprise Edition includes a graphical modeling tool called Data Modeler, which allows you to edit all properties noted above and provides a graphical overview of the process.
Once the Dictionary is complete, the Developer may run the Application Wizard.
|
