[ 1 ] [ 2 ] [
3 ] [ 4 ] [
5 ] [ 6 ] [
7] [ 8 ] [
The VFP 6 Framework andHow to Extend It
What this session, and the VFP 6 framework, is for
When the VFP 6 Application Wizard generates an application for you, what has
it done, and how can you adapt or extend the results?
In this session, you'll see how the framework uses generic Foundation Class
components, and how it implements additional, framework-specific behavior. You'll
learn how and why you'd subclass the framework's application object and other
framework-specific classes, as well as how to quickly "framework-enable"
any form or formset in an VCX or SCX you've created separately.
When you understand the internals of the framework classes and design, you
can exploit the framework fully - or incorporate these ideas into your own framework
and development practices in completely new ways.
What this session, and the VFP 6 framework, is for
This year, I hope I can assume most VFP developers already understand why frameworks
are necessary for developing extensive applications.
You understand the principles of re-use. You have absorbed the value of acquiring
and deploying well-designed class libraries. You want to settle on a robust
implementation of some approach, and invest yourselves in learning to use that
Above all you want to get on with your lives! You want to hang application-
and business- specific elements off the framework to complete your applications
on time and with confidence.
In the past I've encouraged people to build their own frameworks, mining my
own work for ideas. I still think that people learn a lot from doing this, and
that you'll ultimately get the framework you really want if you build your own.
Now, however, I'm more interested in seeing how a team can benefit from using
a framework than what they learn in building it. The short answer to the question
"Why this framework?" is: "because it is designed to benefit
different types, and levels, of developers working together in a team".
This framework may not fit your working style or the UI you prefer. There may
be other reasons why it's not the right framework for you. For one, you may
already be very happy with another framework that you use.
In any of these cases, you should be able to graft this thought - a framework
should benefit a team and enhance the development experience of all its team
members - and some aspects of its implementation onto the framework of your
If that's good enough for you, and if you're not interested in hearing more
about my thoughts on developer team interactions - which underscore the "why"
of framework use - skip over the balance of this section and go right into
the what and how, in the rest of the paper.
The team and the sandbox
Java people use the expression "the sandbox" to talk about the discrete
environment in which a Java applet can exercise influence on the client computer.
They're talking about keeping the sand in and the weeds and dirt out. These
are security and encapsulation issues. In essence they're talking about the
limited environment in which the Java developer can "play", when exercising
influence through the applet.
In thinking about this, I realized that the sandbox metaphor has a wider, more
illuminating validity when applied to frameworks and the development process.
A sandbox isn't a holding pen to keep the kids from crawling around or the
adults from getting sandy. A sandbox is a great place to play. A great place
to play is not just safe and clean, but fun, and full of opportunity. During
truly great play, you learn things, and so does anybody watching you from the
A really good sandbox has facilities to attract adults on its periphery, because
a truly great place to play provides for inter-generational communication. Otherwise
no growth occurs on either side of the relationship. The kids might as well
be in front of re-runs on television, and the adults might as well be at the
Sometimes the adults reach in and suggest a digging toy or another way to improve
a construction in progress. Sometimes the kids are occupied without intervention,
and the adults are perched on the edge, observing and exchanging comments and
ideas amongst themselves.
In standard "pattern-speak", I've just described a model for interaction
between elaborators and abstractors. In "team-speak", I've just describe
the way I think experienced and apprenticed developers should relate as they
go about their daily business of work/play.
I think we need a sandbox-based developer community. How about you?
Building a better sandbox
To make a whole team productive and to give each member job satisfaction, a
framework has to give beginners an opportunity to contribute and construct usable
application elements. They shouldn't have to know much about the underpinnings
of VFP or the framework to do real work (as opposed to exercises).
In this framework, a beginner can construct a form from VFP baseclasses, or
your recommended set of baseclasses, or the Wizard-generated classes, or the
FFC classes, and this form will be both easy to plug into the application and
also properly-behaved under the application. In other words, they can play,
learn, build, and cooperate.
To make a whole team productive and to give each member job satisfaction, a
framework must give experienced developers scope for decision and choice, without
imposing assumptions or limits. It should also be easy to "grow the framework"
with these decisions and choices, so that they are shared for use by the less-experienced
members of the team in a natural way. In other words, senior members of the
team should be able to play, learn, build, and share.
The balance of this paper is about ways this framework allows scope, decision,
growth, and choice and (I hope) will give you the idea that there are very few
limits indeed. That's practically an experienced VFP developer's definition
of a "great place to play", right there!
Shall we get on with it, then?
What you get
The VFP 6 framework application object is a direct descendent of the VFP 5
framework object (not the application object in Tastrade, but rather the one
that the VFP 5 Application Wizard generated). If you ever generated one of the
template applications in VFP 5, some aspects of this application object will
be familiar immediately.
NOTE: If you generated a VFP 5 application and wish to bring it into the new
framework, in fact, almost everything will work perfectly. The only problems
you're likely to find are a few Set
methods you may have
executed (some of these have been changed to assign and access methods in the
new application object). You may also have to adjust the main program slightly,
using the application-specific header file that the new wizard supplies.
On the other hand, this new member of the family has:
- over 200 new custom properties and methods
- a host of new members
- a raft of new supporting classes
- a new and non-main-program-dependent method of instantiation
- the ability to manage toolbars and forms in a "top form", true
- the ability to create modular applications that hook together under one
READ EVENTS or exist in the VFP development environment
- many new features borrowed from the FFC components delivered with the product
- integration with the Project Manager and a new Application Builder through
the VFP 6 Project Hook feature
The last two items I mentioned are especially significant. To be efficient,
a framework should make use of as many standard components as possible. To meet
our goals of effective team use, a framework has to be well-integrated into
the VFP development environment.
If you create a form and incorporate it into a framework application, you shouldn't
have to work hard to tell the framework or the application it's there. The Application
Builder and Project Hook give you this facility.
When you start a new application, to meet our goals of extensibility, the creation
of each new application should go smoothly and allow you to specify whatever
you like about the generated components. The Application Wizard does the "smooth"
part, and later on in this paper I'll show you how to specify all the App Wizard's
generated pieces without sacrificing any "smooth".
Jack-in-the-box is jack-of-all-trades
Because this framework is delivered in the box with VFP, it has a good opportunity
to integrate smoothly with the other features in the box, including the project
The project hook, in my view, is the critical feature that VFP framework developers
have been waiting for as long as there's been a Fox PJX file and APP format.
Of course, this is also its opportunity to teach you how you can integrate your
framework with these features.
Because this framework is in the box, also, it is limited in the assumptions
it can make. It doesn't expect you to follow any particular theory or practice
when it comes to your main job, data handling. It will accept any form of data
buffering and will behave the same way whether you open your tables in the Load,
the Init, or the Data Environment. It will be happy to instantiate forms or
formsets, from VCXs or SCXs.
To be as accepting as I've just indicated it is, this framework must be unusually
stingy about use of the OOP practice known as collaboration. There is no collaboration
required of application-specific items you add into a framework application,
whether they're toolbars, forms, or reports. They can collaborate -- you'll
see that the framework tries to make it easy for them to access various application
features -- it's just not required that they do so.
To use another, more formal, way to express this idea: the VFP 6 framework
is tightly coupled to some FFC components to provide its core functionality,
but it is extremely loosely coupled to application elements you add.
What gives it to you:
a summary of generated and automated components
Here's a high-level summary of the way the framework features are delivered
- The Application Wizard takes your choices for a location and project name,
and generates a project file. It adds a class library with appropriate application-specific
subclasses of the framework's own class library. To distinguish these generated
classes, it adds a special prefix to them all. It adds template-generated,
application specific versions of all the non-OOP components the application
needs. It adds a special suffix to distinguish generated files from other
files in your application. You can see these class- and file- naming conventions
in the sample project shown in the first figure below.
- The Application Builder provides an interface you can use to customize the
framework aspects of any framework-enabled project, throughout the life of
the project. It creates a natural "bridge" between the data sources
that are the life-blood of any FoxPro application and the documents users
need to gather and then display results of this data. It allows users easy
and organized access to the other VFP Wizards that generate application-specific
pieces, including these documents and the underlying data.
- Throughout the life of the project, also, the associated Project Hook object
for a framework-enabled project can help incorporate any new files you add
directly to the project, alerting the framework elements to these new files
- At runtime, a framework-enabled application generates some additional application
files as needed (primarily a user preferences table and, when errors occur,
an error log).
- All these features and files are usable as is. Although a few of the supporting
classes are primarily meant as teaching examples, none are samples you need
to "fix" before they can go into your application. None use "demonstration
data" or other inappropriate assumptions for a shipping application.
That helps beginners drive the framework automatic-transmission style. When
you're interested in doing more work, almost all can be easily swapped for
versions that you prefer, and all can be customized. That means experienced
developers can switch to stick shift whenever they want.
What else you get
Before we go on to "how you get it" in detail, I'd like to draw your
attention to two more of the new features in this application framework, which
are conceptual in nature.
Flexible application types
The framework generates multiple application "types". This is an
example of the framework's attempt to do whatever VFP 6 can do, without imposing
restraints on you.
A "framework-enabled project" generated by Application-Wizard
has files and classes with some standard naming conventions provided by the
Wizard. The Application Builder customizes the generated project, and makes
it easy for you to adjust framework choices.
As you can see in the Application Builder, there are "normal", "top
form" and "module" application types available. By "normal",
the Builder means one in which a VFP application takes over _SCREEN, owns various
global properties (such as SYSMENU, or the ability to CLEAR MACROS or issue
ON SHUTDOWN and ON ERROR commands), and generally brings other activity to a
grinding halt until it finishes executing. When it's good and ready, a "normal"
application has a chance to restore earlier values of these global attributes
before returning control to anybody.
In VFP, as you know, this control of the environment is usually accomplished
with a READ EVENTS statement.
By contrast, some applications have to fit in wherever they're called. Such
an app may be a modaless application you run during your development work. It
may also be a subsidiary application in a larger application you've already
built, which just adds an extra menu pad and choices.
Think of the power of this idea: you can take your already-built application
and give it framework features without touching the rest of it, and without
worrying that this new "framework module" will have untoward effect
on your application's global environment.
Think, also, about building a new, large application out of a bunch of modules,
simply by instantiating two or more framework module application, even deciding
at runtime which ones should exist. The framing program may be another framework
app, or it may be a bare-bones PRG that instantiates the appropriate modules
and adds a READ EVENTS (or not).
Now think a little more about how you may want these applications to look.
Some applications that "own the VFP session" (use a READ EVENTS) may
not work well in _SCREEN. They're more manageable in a separate MDI frame. A
separate frame gives you a more controllable MDI parent window than _SCREEN,
with triggered events you can program like those of other forms. Some applications
that act within other applications, or within the VFP development environment,
may deserve their own frame as well. Think of the Debugger as an example.
These are all things VFP knows how to do. The framework has many properties
and methods designed to make them easy to do.
The designations "normal", "module", and "top"
are just the Builder's way of presenting a whole lot of complicated property
settings and choices available within the framework.
There isn't really any such thing as a "normal" app in the framework,
there are just some "applications that issue READ EVENTS and are allowed
to take over the environment" and "others that aren't". A "top
form" app may share many features with a "normal" or a "module"
framework, depending on what it is supposed to do. A module may, of course,
be added into a top form app as well as a _SCREEN-bound one.
Are these choices, as presented by the Application Builder, the only ways to
mix and match these VFP features and the only possible application types in
the framework? No, of course not. You can change the property assignments of
the application object yourself and come up with other combinations. And other
application types may be made visible in the Application Builder at some point,
|NOTE: The minimal nature of this startup code is deliberate. Among
the application types this framework will be able to support in the future,
obviously the ActiveDoc is a desirable addition. ActiveDocs don't require
a main program at all. They also do not require a READ EVENTS-type environment,
which is one significant reason the VFP 6 framework has been engineered
to work without requiring a READ EVENTS wait state.