Extending DADE

DADE is a flexible and extensible architecture that enables developers to tailor the functionality delivered to meet the requirements of a particular application. The most common ways in which DADE is extended are as follows:

1. Dataview Templates

Create dataview templates to customize the dataview creation process or to provide datapipeline configurations that cannot be created via the built-in query-based dataview.

2. Support for Non-BDE Database

Create native support for a non-BDE database so that the Query Wizard and Query Designer can be used without the BDE.

3. Ask at Run-Time Support

replace the built-in query-based dataview class with one that provides ‘ask at run-time’ capabilities.

4. New Data Wizard

Create a new data wizard.

DataView Templates

A dataview template is a special type of dataview class that has been declared by you, the developer. And while the visual representation of the dataview in the data workspace remains the same as any dataview, the user-interface used to create and modify the dataview is totally dependant on what you want to provide to end-users. Dataview templates can be used for anything from creating predefined relations between a set of tables to integrating a full-blown query builder. In this section, we will show how you can create a dataview template. But before we do, let’s take a look at what the end-user will see when he uses a dataview template.

A DataView Template: the End-User View

When dataview templates are registered with DADE, an additional tab is added to the New dialog. The figure below illustrates what we would see by accessing the File | New menu option within the data workspace:

Here we can see that six different dataview templates have been registered. After double-clicking on the ‘Order’ template, we see the following screen:

This is a custom dialog created by the developer of the Order dataview template. It allows the end-user to enter simple search and sort criteria. Once we’ve done this and click OK, the completed dataview will be displayed:

As you can see in the data pipeline list of this dataview, this template has declared relationships between the customer, order, and order items tables. Each table is independent and has its own data pipeline. By clicking on the Design tab and accessing the Report | Data menu option, we can see how this dataview has assigned the data pipelines to the report:

The customer data pipeline is assigned as the master and the orders data pipeline is assigned to the detail band. The items data pipeline is available, and we could create a subreport and assign it to this datapipeline. This sort of data pipeline configuration is not available from query-based type dataviews, so this is probably one of the reasons why the developer chose to create this dataview template.

A DataView Template: the Implementation
This dataview template is implemented as an SQL query on the customer table with nested detail tables on the order and items tables. Some of the fields from the order detail table are actually supplied from the employee table, which is configured as a lookup table:

A completed and working version of the order dataview template is available in the Demos\EndUser\2. Custom DataView Templates\ directory within the main ReportBuilder directory.

Support for Non-BDE Database
DADE is built upon the concept of the dataview. A dataview is responsible for creating the data access objects required to connect a report to data. A dataview must contain at least one datapipeline. A typical dataview will contain one or more datapipelines, datasources, and datasets. Dataviews are created and maintained visually in the data workspace of the report designer. By implementing new descendants of several classes within DADE, we can integrate a non-BDE database into DADE so that the visual tools provided in the data workspace (i.e. the Query Wizard, Query Designer and custom dataview user-interfaces) can be used with that database.

In the course of normal operation, the Query Wizard and Query Designer require certain information from the database, such as a list of tables from which data can selected, or a list of fields for a given table. These visual tools never directly reference any database objects in obtaining this information, but instead rely on functionality provided by the dataview. This architecture enables these tools to be used without the BDE.

As an example, we have created a dataview descendant that can be used with ODBC98.

ODBC98 is set of native Delphi data access components that provide direct access to ODBC databases without the BDE. The components for the most part mimic the BDE- based components found in Delphi (Session, Database, Table, Query, StoredProc, etc.). ReportBuilder is designed to access TDataSet descendants via the DBPipeline component. Therefore, it can work with ODBC98 seamlessly right out the box. ReportBuilder Pro, however, contains the Query Wizard and Query Designer, which are designed to work with a special dataview class: TdaQueryDataView. Therefore, we must create a descendant of this class in order to integrate ODBC98 with ReportBuilder Pro.

Implementing a QueryDataView descendant requires us to define the following set of classes:

 

 Class Name Description 
 TdaChildODBC98Query ▪ Descendant of TODBC98Query that can be a child of a DataView
▪ Override the HasParent method of TComponent to return True
▪ Must be registered with the Delphi IDE via RegisterNoIcon
 TdaChildODBC98Table ▪ Descendant of TODBC98Table that can be a child of a DataView
▪ Override the HasParent method of TComponent to return True
▪ Must be registered with the Delphi IDE via RegisterNoIcon
 TdaODBC98Session ▪ Descendant of TppSession
▪ Implements GetDatabaseNames, GetTableNames, etc.
 TdaODBC98DataSet ▪ Descendant of TppDataSet
▪ Implements GetFieldNames for SQL
 TdaODBC98QueryDataView ▪ Descendant of TppQueryDataView
▪ Uses the above classes to create the required  Query -> DataSource -> Pipeline -> Report connection
▪ Uses the TdaSQL object built by the QueryWizard to assign SQL to the TODBCQuery etc.