Application Class Hierarchy

The application classes provide certain application functionality to your Iron Speed Designer-applications.  The application classes include important user interface building blocks and database management features that are critical to secure, reliable systems, but can be cumbersome to build.

Iron Speed Designer saves you the time and distraction of re-creating these features for each application.

The application classes extend the .NET Framework to support applications built with Iron Speed Designer.  The application classes are provided in source code and compiled form by Iron Speed Designer.  Applications built with Iron Speed Designer use classes inherited from other application classes and .NET Framework classes.  Your application’s classes themselves inherit from the Microsoft .NET Framework classes.

Application classes are generally derived from .NET Framework classes.

For example, the default page class used by .NET is System.Web.UI.Page.  This class is sub-classed in the application classes as BasePage.  Applications use this class for individual pages.

The purpose of the application classes is two-fold.  First, the application classes provide extensions to the Microsoft .NET Framework to deliver additional functionality.  Second, they enable you to add features that apply to the entire application by making changes to these classes.

This section documents the application classes and the methods that are the most likely candidates for making changes.  The application classes may contain several additional classes and methods not documented here that provide additional internal support.  We do not recommend changing any of the internal classes and methods.

Presentation Layer Classes

In the Presentation Layer, Iron Speed Designer creates these class types:

Many class hierarchies contain customizable classes that are created once and never overwritten.  The customizable classes are usually the lowest level classes so you can override any class or method in your application’s class hierarchy.  By adding your application-specific code to the customizable classes, you are free to extend or replace functionality without worrying about your extensions being overwritten by subsequent updates.

Data Access Layer Classes

The Data Access Layer classes provide the infrastructure to handle data from a database.  In the Data Access Layer, Iron Speed Designer creates these class types:

The Data Access Layer classes provide controls for columns, records, table utilities and tables (your application database schema).  These controls work together to capture all the schema information needed to compose and display the different tables required by your application.  These controls include the functions to display a list of record data inside a table or retrieve a record that includes specific field values.

The naming convention for the Record class is:

<TableName>Record

<ViewName>Record

<QueryName>Record

For example:

CustomersRecord  (table name is "Customers")

vwEuropeanCustomersRecord (view name is "vwEuropeanCustomers")

qUSCustomersRecord (query name is "qUSCustomers")

The naming convention for the Table class is:

<TableName>Table

<ViewName>View

<QueryName>Query

For example:

CustomersTable                                  (table name is "Customers")

vwEuropeanCustomersView            (view name is "vwEuropeanCustomers")

qUSCustomersQuery                                         (query name is "qUSCustomers")

Let’s say you want to write a function to get the full name of a customer and the database only contains the first name and the last name.  This type of code customization is best created in the customizable class file for the <Table>Record class.  On the other hand, if you want to add a customization that deals with a group of records such as getting the maximum number of records, or modifying the default filter or sort criteria for *all* access from this table, then you can customize the <Table>Table class.

Please note that if you modify the behavior of the <Table>Table class, you would modify the behavior for *all* access from your application.  If you want to just do some specific modification for a single access, then you are better off doing that at your page level, and not modifying the underlying behavior of all calls to retrieve the data.

There are other helper classes such as <Table>SqlAccess and <Table>Definition.

Page-related classes

Page Classes

BasePage Class

Record-related classes

Record Classes

PrimaryKeyRecord Classes

VirtualRecord Classes

BaseRecord class

Table-related classes

Table Classes

PrimaryKeyTable Class

VirtualTable Class

BaseTable Class