5
|
|
5 |
|
|
The LA Fox DeveloDer Newsletter
|
|
October 1997
|
|
Frameworks...
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 published 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 updates 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 foundation 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 implementation. 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 management 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 implemented.
Business objects, the second tier, represent single entities such as customer, invoice or vendor. Business objects implement 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 implement 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 functionality, look and feel.
Here are some of the downsides to Codebook from my experience. 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.
|
|
Page 5
|
|
|
5 |
|