The LA Fox DeveloDer Newsletter

October 1997

Frameworks...

Codebook 3.0

by Mike Vincent, President/OCFUG

Foundations are not necessarily rapid development tools, but a

good framework that will save you lots of time. With a good

foundation, you will have many of the tools necessary for

building a solid application available to you. Selecting the

foundation that best suits your own needs is important. Some

are more flexible that others. Some are great for short, quick

projects while others are appropriate to larger projects and

overkill on small jobs.

Does the foundation provide the look and feel you want to

provide to your users? Can you easily modify it if necessary?

What kind of support is available?

Visual Foxro 3 Codebook

The Visual FoxPro 3 Codebook by Yair Alan Griver was pub-

lished shortly after the release of Visual FoxPro 3.0 and is

available for less than $40 in most book stores. Written as a

book with accompanying CD rather than a commercial software

framework, I consider it a real bargain. Don’t expect any up-

dates on Codebook from YAG ( he says he is retired from

writing books) but on the other hand it is still current on VFP 5

and enjoys good peer and 3rd party support.

The Codebook foundat;on is well written and rnplemented. It is

based on solid object oriented principles and has a lot of depth.

It also requires a heavy investment to learn and use the founda-

tion effectively. Codebook can scale well for larger projects but

is an overkill for small, quick and dirty applications.

The foundation framework consists of a series of foundation

classes from which application specific subclasses can be

derived. The foundation classes are grouped into interface

classes which deal mostly with presentation (forms, toolbars,

etc.), control classes which control the flow of the system and

interaction of components, and entity classes which wrap

functionality around the data entities of the application

A main application class provides a central point of implementa-

tion. Some of these duties include setting up the application’s

initial environment, splash screen display, providing access to

global settings and user preferences and implementing READ

EVENTS. The application object (goApp) is accessible from

anywhere within the application.

The internal architecture of Codebook is heavily based on

collections. Nearly every object is a member of some collection

with collection containers providing access to the collected

objects. Good object oriented principles are followed closely. To

the extent possible, classes don’t make assumptions about the

state of the environment they are being implemented in. They

change the environment when necessary and clean up when

finished. Each class definition also performs a single task,

relying on other classes when a function is outside the scope of

responsibility for that class.

The Codebook approach to data handling utilizes a three tier

model. The first tier interface classes are completely separate

from the second tier business object classes. The third tier is

the data or back end tier which represents the physical man-

agement of data. This is where data integrity rules and stored

procedures reside.

The first tier objects include form clases. Each form knows how

to add and remove itself form an applications forms collection,

how to change its caption to indicate multiple instances of an

open form, how to refresh the menu system when it’s activated

or deactivated, and how to save its size and position when it’s

destroyed so it can use these settings next time it is imple-

mented.

Business objects, the second tier, represent single entities

such as customer, invoice or vendor. Business objects imple-

ment the required data environment and can contain rules that

enforce the validity of data entered or edited by users. They can

also contain visual controls that represent the entity in the

interface or they can be completely non visual with hooks for the

visual controls used in different instances. Most of the data

navigation and management functionality exists in business

objects.

The three tier architecture of Codebook makes it easy imple-

ment your applications with local Visual FoxPro tables or

remoteODBC data sources such as SQL Server, Oracle or

DB2: You need to utilize views for all data access, whiäh is

easy with Codebook, to accomplish this.

Codebook implements menus as objects through a series of

wrapper classes and data is managed as objects through non

visual classes. Many utility and developer tools are included

such as a class that wraps the functionality of FOXTOOLS.FLL

and Ken Levy’s SuperClass utility and the Flash Standards

utility for headers and comments in your code.

I utilize Codebook extensively for my company’s VFP projects.

After two passes at developing our own foundation and working

with another company on development and implementation of a

“from the ground up” foundation, I have settled on Codebook.

We have modified and extended it to meet our needs for func-

tionality, look and feel.

Here are some of the downsides to Codebook from my experi-

ence. There is overhead — Codebook has a lot of depth but there

sometimes can be a performance penalty. Directly off the CD,

multiple child instances are not supported and there is no

security. These issues and many others are addressed by 3rd

parties and peer support. Finally, the learning curve is steep and

it’s easy to blow off something as not workable because of not

fully understanding what is going on.

(Con't, page 6)

Page 5