As a Visual FoxPro developer you know that the most important tool in your development tool chest is a good development framework. However, we all know that developing these frameworks is not as simple a process as it seems. It takes time and energy to develop, refine and implement a good framework. This session will discuss techniques for developing your own frameworks, without the hassle and headaches. In this session you will learn:
It sometimes seems that the hardest part of developing a framework are the first few steps. Eventually you do begin and what happens from there can sometimes prove to be very interesting, So where do you begin ?
The first thing you need to concentrate on is how your class libraries and designs are going to be organized. When you begin your framework development you need to break your class libraries into functional areas. You could store all of your class designs in the same class library but this is not practical as if you cannot find a class you cannot use it. So how do you break your class libraries into functional areas ? Well here we go.
Included on the conference CD is a set of class libraries known as the FoxPro Foundation Classes. These class libraries are organized to facilitate quick access and functional usage. The class libraries found in the FoxPro foundation classes are:
| CLASS LIBRARY/PROCEDURE FILE | Description of Purpose |
| MAIN.PRG | This is the main launching program. |
| LIBRARY.PRG | This file contains global user defined functions. |
| BASECLAS.VCX | This class library contains the most primitive base classes. |
| FORMS.VCX | This class library contains commonly used forms. |
| WIDGETS.VCX | This class library contains useful application development classes. |
| RASLIB.VCX | Classes for calling Dial Up Networking from your VFP appliations |
| DATACLAS.PRG | A data manager class for creating three tier database applications. |
| HTML.PRG | A class that can be used to create HTML web pages. |
| ACTIVEX.VCX | Subclassed ActiveX controls. |
| OFFICAPI.PRG | Classes for communicating with Office applications. |
As you can see this set of class libraries breaks Visual FoxPro development down into many useful and functional areas. If you look at this set of class libraries as a hierarchy you will see something like
As you can see the most primitive set of classes exist in the BASECLAS.VCX and all other classes are derived from there. So what is in BASECLAS.VCX ? BASECLAS.VCX contains sub-classes of all of Visual FoxPro's base classes. These classes for the most part are simply default classes with no property or method changes. The only changes made to these base classes include: global properties, font and sizing defaults, code in the page frame to refresh all pages, and code in the list/combo box to handle refresh issues. The idea behind these classes is to be able to use them on any form, container or dialog with no functional dependecies, which leads us to the first major problem with framework design: CLASS LEVELING
Beware of CLASS LEVELING Problems One of the most common problems with framework design is to create primitive classes that do too much. I have seen many classes where the most primitive classes are loaded with functional dependencies. These classes constantly look for the existence of other objects, properties and variables. If you find yourself constantly overriding methods of class to shut of functionality you probably have not properly leveled your classes. |
After establishing a set of base classes you are ready to begin creating more specialized classes. The classes shown above subclass from classes found in BASECLAS.VCX to create more specialized classes. Each of the subclasses created has a particular job and function in actual applications. The best one to look at is FORMS.VCX. The most common thing you do in your Visual FoxPro applications is the process of creating forms. There are different types of forms. There are data entry forms, dialog boxes and report output forms. The forms hierarchy found in the FoxPro Foundation Classes looks like:
As you can see this set of classes defines some of the major classes that you will use to create applications. If you needed to create a dialog box you could sub-class frmDialog or if you need a data entry form with buttons on it you can select the frmDataEntryWithButtons class. The idea is to create a set of classes that become more specialized as they go further down the inheritance hierarchy.
One of the most overlooked and most problem areas of creating frameworks is a lack of documentation. CodeBook suffers from this problem. Codebook is probably a great framework but the world may never know because it lacks a good set of documentation. Not to pick on my friends at Flash Creative Management, I just wish the documentation had been about double the size it was. So how do you document your classes. Below you will documentation for the frm_progress_dialog class found in the WIDGETS.VCX file:
| Class Name | frm_Progress_Meter |
| Description | This dialog is a progress meter. It graphically shows a what percentage of a process has been completed. |
| Parent Class | frm |
| Classes Used | frm, shp |
| Public Properties | nIncrementValue (default 1) nMaxValue (default 100) |
| Private Properties | nCurrentValue (default 1) |
| Public Methods | IncrementValue (This method increments the nCurrentValue property using the nIncrementValue property. It then increments the progress bar changing the width of the shp_progress_bar using the formula 400 * (nCurrentValue/nMaxValue) |
| Private Methods | NONE |
This table documents all of the information that a developer might need when using this class. It includes a description of the classes purpose, the public properties and methods and any internal methods that developers. As my friend Steve Black said "Its the interface stupid." (Just kidding he didnt't say that but he would <G>). If your class libraries are not documented they will not be used. Which means they will be re-developed. This documentation is probably the minimum you should have. Some other items you should include are: more detailed descriptions of the properties and methods, sample code using the class and a diagram showing its inheritance hierarchy. How much documentation you include depends on your own needs.
Beware the OOP monster. Every program you write and every function you create do not need to be classes or members of some class. Visual FoxPro is a hybrid language like C++, Delphi and other great OOP languages. What this means is you can still use User defined functions in your applications. Looking at the classes and code libraries provided with the FoxPro Foundation Classes you will find that there is a set of user defined functions found in LIBRARY.PRG. These function perform tasks such as asking yes/no types of questions of users, locking records and refreshing views. You are still allowed to preserve what you already have developed in FoxPro 2.x, dBASE or Clipper. You do not need to turn all code into objects. Which brings up the next topic:
One of the lesser used capabilities of Visual FoxPro is its ability to store class definitions in .PRG files. It is common for developers to create all of their classes using .VCX files. There is absolutely no problem with this approach. However, you may want to think about putting some classes in code for readability and maintainability sake. In some cases it is easier to look and modify a class as a single source file rather than having to go into many different classes in the Class Designer. The FoxPro foundation classes takes the approach that Visual Components go into .VCX files and non-interface style classes go into .PRG files. Either approach is valid.
Now that you have an understanding some of the techniques you can use to develop frameworks you can look at some of the commercial offerings out there. Some of the commercial frameworks include:
Each of these frameworks has its own set of unique capabilities and problems. If time allows we will look at some of these frameworks.
Hopefully, you will leave this session with a few new techniques and ideas that you can incorporate into your development frameworks. At a minimum you should be able to judge the quality of a framework by applying some of the criteria provided in this session.