OOPS Proper: What's an obtainable goal for centralized code in Visual DataFlex?

*Click on image to enlarge please...

OOPS proper coding goal is "no code in objects except property settings", is this obtainable?

The Visual DataFlex Studio and Database Builder utilities are the tools we use to build applications, and the coding style used in actual practice varies from "artist" to "artist" as much as a painting style does.

While the true goal of object oriented style of programming is to truly centralize code, and to produce an application where all customization departure from the basic tools we use should reside in classes, not objects. Further to this, each class has property settings for given or endowed abilities which allow us to re-use the class as instantiated in an object in different settings with different results depending on need.

Here is an example of such "art" in the fact that a module of data entry is first programmed with object code for the desired result, tested.... and then the code is moved to the classes involved for centralization and standardization. Standardization is a fundimental concept where you desire the same behavior in all modules or a programmed variance of same behavior, all set in a central place.

Visual DataFlex allows the programming and testing of object code rather than specifying that all instantiated objects be pure classes.

The "art" to this simple example as illustrated can be taken to many varying ways of implementation. One of the true advantages of VDF is the concept of multiple-inheritance.

Here's the challenge that multiple-inheritance solves:

We have a property setting "Set Auto_Clear_DEO_State to False" and a function SAVEHEADER which really belong both to the cWSdbView and cWSdbModalDialog class as well as possibly a cWSdbTabPage.

Shall we type these into the three classes three times? I think not! Remember our rule of thumb where "when you type code twice, it's time to rethink your methodology", and here's a solution using a MIXIN class. The MIXIN class is "mixed into" a class layer in addition to the regular superclass inheritance. Here's how.

click on image to enlarge please

Visual DataFlex - Organization Foundation

Visual DataFlex:

an outline:

• - Workspace


• - Project


• - Layers

Workspace:

A Workspace is defined as an organization of resources supporting an application in subfolders defined by the workspace. Standard Layout of a Workspace (with no modification) is;

• - AppHtml - .asp code and supporting images plus cascading style sheets, etc.


• - AppSrc - windows source code


• - Bitmaps - images


• - Data


• - DDSrc - data dictionary class layers and table definitions


• - Help (blank)


• - IDESrc - vdf class information


• - Programs - executables and workspace definition file plus debugging tracer code

So, with the advent of Vista, and the desire not to place our live app within the PROGRAMS folder, an actual deploy model would look like:

C:\Visual DataFlex Projects\MyWorkspaceName .... with subfolders.

PROJECT: A project is defined as a workspace application (there may be more than one project inside a workspace) executable.

A Project is usually a MDI (multiple dialog interface) application with the following layer structure:

DESKTOP:=================================

• - The Desktop is the name for anything outside the inner containers


• - The Desktop contains an application object which defines the paths and behaviors associated with the application.


• - The Desktop contains: the MAIN panel, the CodeJock skinning, and possbily a Login Panel?

MAIN: ====================================

• The Main is a SDI panel which functions as a main container object for the application.


• The Main contains the MENU


• The Main contains the CLIENT_AREA : the container for interactive modules/objects.

APPCLIENT_AREA:==============================

The APPclient_area is the working ground of all major components of your system.

It contains:

• Data Entry Forms


• Reports


• Selection Lookup Lists


• Modal Dialogs


• Business Process Objects


• Resources such as methods and classes

All Together, the workspace, as described, is designed to let delegation, encapsulation, and polymorphism happen within the context that the modules and sub_objects are arranged.

All Together, it looks like the picture above: click on image for larger view!

Regards,

Peter A Donovan, Applause Software

http://www.applausesoftware.com/