Session V-MM

The Mere Mortals Framework

Kevin McNeish
Oak Leaf Enterprises

Contents

This session demonstrates:

  • How the Mere Mortals Framework helps you create highly optimized applications that run on the desktop and easily scale to multiple tier architectures, including client-server and can also be accessed via the Internet.
  • How our development environment helps you create robust applications quickly without forcing a particular “look and feel”.
  • Why many small and large development teams around the world have chosen the Mere Mortals Framework as their primary Visual FoxPro development tool!
  • How Mere Mortals allows you to make full use of the latest advances in Visual FoxPro cursors, ADO RecordSets , HTML and XML

Why the Mere Mortals Framework?

The Mere Mortals Framework has been chosen by hundreds of Visual FoxPro development shops around the world as their primary tool for creating applications. Here’s some of the reasons why:

It’s Fast!

We hear this over and over again from developers using our product—especially those moving from other frameworks. Applications created using the Mere Mortals Framework run very fast because they are built on a foundation of highly optimized classes. Optimization is one of the most critical considerations we bear in mind when adding new functionality to the Framework. We believe that a good design is both object-oriented and optimized.

It’s Object-Oriented 2

The Mere Mortals Framework is a study in the application of solid object-oriented design principles. Its object model is clear and easy to understand, while taking advantage of the latest in object-oriented technology. Our application of design patterns such as the Abstract Factory, Bridges, Subjects & Observers, Strategies and object composition make the Mere Mortals Framework and your applications, extremely flexible and scalable. We’ve even created Event Sources and Receivers that allow you to raise your own custom events within your applications!

Our documentation does much to help you learn to apply these principles in your own applications. Mere Mortals also includes model files that can be used with both Visual Modeler and Rational Rose to help you understand the structure and design of the Framework.

It Helps you Create Highly Scalable Applications

Many developers realize they eventually need their applications to scale to other architectures—such as client-server, or even the Internet. Mere Mortals helps you build applications that work great on the desktop, but can also easily scale to multiple tier architectures. In contrast, most other Visual FoxPro frameworks are designed for one or two tiers.

It Doesn’t Force You into a Mold

One of the biggest complaints we hear about other frameworks is that they force your applications to have a particular “look and feel”. Others find that it’s nearly impossible to “color outside the lines” because the framework has a rigid set of constraints that must be followed. In contrast, the very structure of the Mere Mortals Framework makes it easy to adapt to your needs. For example, Our Abstract Factory allows you to easily substitute Framework components with your own custom components.

You Can Create Applications Quickly

The Mere Mortals Framework is not an application generator! However, our data-driven Framework builder is a RAD tool that allows you to create applications quickly. Since the Builder is data-driven, you can easily adapt it to work with any non-Framework classes that you may use.

Business Objects – The Key to Scalability

The Mere Mortals Framework allows you to create highly scalable applications. You can create a single application that accesses both Visual FoxPro data and client-server data—and allows you switch between them dynamically at run time. You can also create a single application that runs on the desktop, and can also be accessed from a wide variety of products such as Microsoft Office and even the Internet! The key to this scalability is our business object classes.

What is a Business Object?

A business object is a high-level abstract object that represents a person, place, event or business process. For example, in a point-of-sale invoicing application, you might have business objects that represent Invoices, Inventory, Customers and Orders. Each one of these objects represents an entity in the real world. Although the concept of business objects can be difficult to grasp at first, once you understand the concept, they make applications far easier to understand, create and maintain.

A good example of the implementation of business objects is the Microsoft Office suite. Each product in Microsoft Office possesses “business” objects that can be accessed programmatically by means of Automation. By calling methods of these objects you can programmatically perform any task that can be performed manually, such as creating documents, pasting text, deleting text, printing, and so on.

The collection of objects that comprise an application are known as its object model. To get a better idea of how to design an object model for your own applications, it’s helpful to examine the object models of products found in the Microsoft Office suite. As shown below, you can view any Microsoft Office object model by loading its type library into Visual FoxPro’s Class Browser.

To load a Microsoft Office type library in the VFP class browser, click the browser’s Open button. In the Open dialog, select *.olb in the Files of Type combobox then navigate to your Microsoft Office directory and open the desired type library.

The table below lists the names of both Office 97’s and Office 2000’s type libraries.
Product Type Library

Access 97

MSACC8.OLB

Excel 97

MSXL8.OLB

Outlook 97

MSOUTL8.OLB

PowerPoint 97

MSPPT8.OLB

Word 97

MSWORD8.OLB

Access 2000

MSACC9.OLB

Excel 2000

EXCEL9.OLB

FrontPage 2000

FPEDITAX.DLL FRONTPG.EXE

PowerPoint 2000

MSPPT9.OLB

Word 2000

MSWORD9.OLB

Why You Should Use Business Objects

Business objects are used in applications for three main reasons:

  1. Encapsulation and Reusability of application logic
  2. Scalable data access
  3. Enforcement of business rules

Encapsulation and Reusability of Application Logic

Rather than spreading your application logic throughout your application lurking behind Click, Valid and Whenevent code, business objects encapsulate related application logic. For example, an Invoice object contains all the logic pertaining to Invoices—printing, deleting, purging, calculating totals, tax, and so on.

Using business objects also provides a great deal of reusability—both inside and outside of Visual FoxPro. Most developers place reusble application logic within function and procedure libraries stored in .prg files. While this is good for reusability from within Visual FoxPro, the reusability ends there—only Visual FoxPro can run the code stored in these procedures and functions.

COM Business Objects

In contrast, if you store your application code in the methods of business objects, these objects can be marked as OLE Public and compiled by Visual FoxPro as COM objects in Automation Servers. This allows any application that knows how to instantiate COM objects—Microsoft Office products, Delphi, J++, C++ and Visual Basic—to access your application logic.

Accessing Your Applications from MS Outlook!

Not only can you access Microsoft Office products from Visual FoxPro, using the Mere Mortals business objects, you can have Microsoft Office access your applications! For example, you may have wondered how you can get MS Outlook to access your application’s data. The answer is business objects! They allow Outlook and other applications to read and (if you allow it) manipulate your application’s data.

Accessing Your Applications via the Internet

One of the most interesting technologies that can access your application’s COM objects is Microsoft’s Active Server Pages. By means of Active Server Pages, you can access your application logic that is stored in COM business objects. So, if you store the majority of your application logic in business objects, you are well on your way to creating an application that runs both on the desktop and via the Internet.

Accessibility within Reason!

How much of your application can be accessed by means of Automation is completely up to you. You can surface as little or as much of your application as you want. Only objects marked as OLE Public can be accessed via Automation. In addition, only the properties and methods of objects with a public scope can be accessed on a COM object.

Business Object Architecture

As shown in the UML class diagram to the right, our business objects are composed of three major components—a UI-Centric object, a Data-Centric object and a Business Rules object.

Using object-oriented composition to break out the major functionality into three main parts provides a great deal of flexibility.

The UI-Centric Object

The UI-Centric object is the part of the business object with which your applications directly communicate. It contains the majority of your application’s logic.

This object can be:

  • Dropped on a form and directly accessed from form methods
  • Dynamically instantiated from a Visual FoxPro class
  • Instantiated as a COM object from an Automation server

The Data-Centric Object

The Data-Centric portion of the business object is responsible for loading, unloading and manipulating your application’s data. It can be swapped out to change its data behavior without affecting the rest of the application. It can also be distributed to another computer on the network in a true three-tier distributed architecture.

Business Rules Object

The fact that business rules are separated into their own business rules object allows business rules to be easily changed—even dynamically switched at run time.

The Business Object Builder

As shown in the diagram below, our Business Object Builder provides the visual tools you need to create your application’s business objects. By default, Visual FoxPro does not provide a visual tool for creating data environments outside of reports or forms. Our Business Object Builder simulates Visual FoxPro’s Add Table or View form, allowing you to specify which tables and/or views should be loaded by your business objects. This provides all of the flexibility not available in Visual FoxPro but with the same convenience of a visual IDE.

Scaling to Client-Server

Even if you do not have immediate plans to move to client server, the Mere Mortals Framework guides you in creating an application that can easily scale to client server when you’re ready to make the move.

When you use business objects to load your applications data, it provides a layer of separation between the user interface (tier 1) and the data (tier 3). This provides a smooth transition from Visual FoxPro data to client-server data. The architecture allows you to vary the back end data without changing your application.

Many developers using the Mere Mortals Framework take advantage of this feature by selling both a Visual FoxPro and a client-server version of their applications. The Mere Mortals Framework makes this a very smooth transition—and unlike many other solutions it’s not a one-way street. Once you upsize to client-server, your application still works with Visual FoxPro data. 

Switching between local and remote data is as easy as clicking a checkbox. You can also use this Framework form to allow users to dynamically switch between application data sets.

Application Security

User/Group-based Security

The Framework allows you to specify which users or groups of users can have access to a particular form, page, UI control (or sets of controls), menu pad or menu bar. The security model is data-driven making it extremely flexible.

Types of Access

By default, the Framework has three access levels: Full Access, Read-Only Access and No Access. Access can be specified at the user interface control, menu pad and menu bar levels.

Full Access

This specifies that a user has full access to the specified area of the application and can view / change the data associated with the user interface (UI) control.

Read-Only Access

This specifies that the user can view data associated with the user interface control, but cannot change it.

No Access

This specifies that the user cannot view or change the data associated with the user interface control. If the user has no access to a particular user interface element the control is hidden from the user. For example, if a user has no access to a form they don’t even see the menu bar or toolbar button that launches that form.

Setting Application Security

When application security is enabled, the User and Group forms possess an Access tab from which you can specify the access level that for all secure controls:

Security Setup Mode

In addition to the User and Group forms, the Framework also allows the end user to specify access to controls by means of “Security Setup Mode”. If a user has access to the “Menu – File | Security Setup” menu bar, an additional Security Setup menu bar is added to their File menu pad.

When the user selects this menu option, it sets the application in Security Setup mode. In this mode, all user interface controls that are marked as secure are displayed with a yellow container around them.

If the user right-clicks a secure control, it launches the Application Security form. This form allows you to specify which users and groups have access to the control and at what level. 

 

Creating Applications Quickly

One of the main tools provided by the Framework for creating applications quickly is the Mere Mortals Framework  builder. Here are a few examples of the Framework builder.

The dialog to the right allows you to visually set a object’s ControlSourceproperty. The Database combobox is data-driven allowing you to select different database containers. You can select the view/table and field from the listboxes. When you click OK, the selected cursor.field value is stored in the object’s ControlSource property.

Grid Builder

Right-clicking on one of the Framework’s grid classes launches the Mere Mortals Builder with the following controls:

Here is a description of each Builder control:
Property Description

Name

Specifies the name of the grid.

RecordSource

The RecordSource of the grid. Unlike VFP, changing the name of the RecordSource using the Mere Mortals builder does not clear out the column ControlSources!

Columns

The number of columns in the grid. When new columns are added to the grid by means of the Builder, both the column header and column control are set to the default font specified in the Font Size box. In addition, if you specify a class in the Default Column Control box, the Builder will add a column control based on that specified class. If the Default Column Control box is empty, the Visual FoxPro default textbox control is added to the new column.

Font Size

The default font size of all columns, headers and column controls. As you change the value, the font size of all objects in the grid are automatically changed accordingly

Lines

Grid lines. Options are:0 – None, 1 – Horizontal, 2 – Vertical, 3 – Both

Header Spaces

The number of leading spaces in the header. One or two leading spaces can often improve the appearance of header text. This setting is only applied to column headers whose Alignment is set to one of the following values: 0 - Middle Left, 4 - Top Left, 7 - Bottom Left

Delete Mark

Specifies whether the delete mark column appears in a Grid control

Read Only

Specifies whether the user can edit the grid

Movable

Specifies whether the columns can be moved by the user at run time.

Resizable

Specifies whether the columns can be resized by the user at run time.

Enabled

Specifies whether the grid is enabled.

ControlSource,

Width,

Alignment,

Read Only,

Sparse,

Header Caption

All of these properties apply to the grid column/header. A record is displayed in the builder grid for each column in the grid.

Default Column Control

Specifies the class of the column control to be used when adding new columns to the grid. The value in this box is taken from the grid’s cColumnControlClassproperty. This allows you to set different default classes for different grid instances.

 

Framework User Interface Classes

Here is a sampling of just a few of our many user interface classes that you can use in your applications:

Side Bar Form

The Side Bar Form class provides a way for you to create Internet Browser-style side bars for your applications. Typically, the Side Bar form is loaded at application startup and stays active until the user exits the application. You can place regular or graphic buttons on the Sidebar from which the user can launch main application forms. You can also place a TreeView in this form that provides application navigation.

 

List forms

This type of form contains a list (Grid, TreeView, etc.) on the first page of the pageframe from which you can add, edit and delete records.

This type of form works well on client-server tables with no more than a few hundred records. You can also use this form in client server systems with large tables by limiting the number of records in the list with a control, such as a combobox that is tied to view parameters. This form also works well against any size VFP tables.

 

Non-List forms

When first loaded at run time, this form presents a blank record to the user. To select a record for editing, users can click the Find button, and launch the find form shown below. 

 

Find Forms

The Framework’s Find form allows users to launch a separate Find form (similar to the Windows Explorer find form) that allows them to enter search criteria, view the “Records Found” and select a record for editing.

If the Close Window On Select button is unchecked, this window will stay open, allowing the user to visually select the next record to be edited, rather than using VCR buttons. 

 

Date List Control

The Date List control allows the user to select one of the following date ranges:

    Current Week, Current Month, Current Quarter,
    Current Year, Month-to-Date, Quarter-to-Date,
    Year-to-Date, Last Week, Last Month, Last Quarter,
    Last Year, Life-to-Date, Next Week

When the user selects one of these values, the corresponding Date From and Date To dates are auto-filled.

Error Handling

The Mere Mortals Error Handler serves three main purposes:

  1. Protects the application’s data
  2. Records errors in a log so developers can determine why an error occurred
  3. Catches errors at development time

The Mere Mortals Framework Error Handler is based on the Chain of Responsibility design pattern. The error handler logic passes errors up the container hierarchy. When an application encounters a Visual FoxPro error, the Error method of the currently active object is fired. If the active object does not know how to handle the error, it passes the error off to its parent object that may know how to handle it. This gives more than one object the opportunity to handle a particular error.

The user can view application errors in the Event Log form. This form gives detailed information regarding application errors including information on the user’s computer environment and the calling chain of the application error. 

OLE Drag and Drop Objects

The Mere Mortals Drag-and-Drop objects are programmer-definable objects that can be placed on forms or other user interface controls at design time. At run time, users can drag these objects onto the application desktop, creating “shortcut” desktop objects. Shortcut objects are displayed as an icon with associated text similar to those found in Windows 9x. They contain “instance-specific” code in their Double-Click methods based on the type of object that was dragged onto the desktop by the user.

For example, as shown in the illustration below, there is a small “hand and paper” icon on the Projects form. Users can drag this object onto the application desktop, creating a new Shortcut object that is linked to the currently selected Legal Resources record and the Projects form. At a later time, when the user double-clicks on the Shortcut object, it launches the Projects form with the “Legal Resources” record already selected.

The Mere Mortal Framework

This is just one of the many tasks that can be accomplished with the Framework’s Drag-and-Drop objects. The illustration also shows an Outlook shortcut located on the desktop. If a user drags and drops a client onto this shortcut, it can do a variety of things such as automatically add the client to Outlook’s contacts, or send an e-mail to the client. The possibilities are only limited by your imagination. 

Integration with 3rd Party Products

The Mere Mortals Framework integrates with some of the most popular Visual FoxPro 3rd party products. With subsequent versions of the Framework, we will continue to integrate with additional products.

The Framework’s CCompnet.vcx library contains classes used to integrate with 3rd party products. As shown in the diagram to the right, CComponentis the base class for all 3rd party product classes.

Stonefield Database Toolkit

Stonefield Database Toolkit is a 3rd Party product from Stonefield Systems Group. It provides Visual FoxPro with a true data dictionary and overcomes many limitations found in Visual FoxPro. For more information, check out Stonefield’s web site at www.stonefield.com.

Steven Black’s INTL Toolkit

Steven Black’s INTL Toolkit is a 3rd Party product that makes your Visual FoxPro applications multilingual. For more information on INTL, check out Steven’s web site at www.stevenblack.com.

FoxAudit

FoxAudit is a 3rd Party Product from Take Note Computer Consulting. It provides your Visual FoxPro applications the same transaction logging capabilites that are native to large RDBMS like Microsoft SQL Server and Oracle. For more information, check out Take Note’s web site at www.takenote.com.