A Bit of History
In the beginning, there was VFP 3.0, and a myriad of 2.6 programmers fumbled with object-oriented programming. The idea of reusable code and encapsulation eventually translated into discussions on framework designs. One of the earliest frameworks came from the folks at Flash Creative Management (recently bought by GoAmerica) shortly after the release of VFP 3.0. Dubbed Codebook 3.0, it was as object-oriented as object-oriented could get at the time. Even the menu system was wrapped in objects to facilitate communication between the menu system and the rest of the framework components. Unfortunately, the documentation left a lot to be desired, and its advanced object-oriented design intimidated a lot of developers new to VFP.
To make matters worse, Flash’s vision was way ahead of its time. Flash knew COM was coming, and it tried to position itself for the new technology by encapsulating business logic into business objects away from the user interface. But COM wasn’t ready until several years later. As a result, many developers had difficulty grasping the idea of separating the business logic from the user interface and many applications did not follow the logical three-tier approach. When it came time to scale the applications with COM, they found it to be a major undertaking to separate the two tiers from each other. Those who followed the Codebook approach to the letter found the transition to true n-tier development a snap.
Mere Mortals is Born
One of the early users of Codebook, Kevin McNeish of Oak Leaf Enterprises, started documenting the framework for internal purposes. Realizing that others may benefit from his efforts, he posted the document on Compuserve in 1995, calling it "Codebook for Mere Mortals". The document fixed a number of bugs and incorporated several enhancements.
In 1997, Kevin worked out an arrangement with Flash and began development of his own version of Codebook. Called Mere Mortals, Kevin's version was much easier to use, with lots of builders and excellent documentation. Kevin shared Flash’s vision of the DNA approach, and he emphasized again and again in his documentation the importance of separating the business logic from the user interface.Over the years, Mere Mortals changed quite a bit-as did Codebook. The two frameworks went in different directions. Most notably Codebook is distributed free and Mere Mortals is not. As developers became more fluent with VFP and n-tier development, many developers complained about Codebook's heaviness. Although Mere Mortals was lighter, thanks to its abstract factory, many still considered it too heavy, and complained about the framework's lack of use of the Windows' DNA. Both frameworks supported client/server architecture, but most of the support was for remote views, with little support for SQL pass through or remote transaction handling. Eventually, Flash released COMCodebook, which is strictly a middle tier framework. COMCodebook is also distributed free. The original Codebook framework, now up to version 6.0, is still available. The two frameworks can be used together to build enterprise solutions, but COMCodebook is a more generic approach to building middle tiers, leveraging VFP’s data handling capabilities for business objects.
This ain't your daddy's Codebook anymore!
Oak Leaf's latest release is the culmination of several years' input from many developers. The biggest change is its adoption of the Windows' DNA, using the Executant and Emissary models for communication between tiers. "I have rewritten every square inch of the framework," said Kevin. Even for long-term users of the framework, some head scratching goes on as they look at some of the newer features. Basically, tier one uses the Emissary object to communicate with tier two-the Executant. The business rules normally reside with the Emissary object and are validated before sending the data to the Executant to limit network traffic. The Executant is responsible for communicating with tier three-the data. The transport mechanism between the Emissary and the Executant is XML, but ADO can also be used as well. Oak Leaf recommends that XML be used instead of ADO because XML is faster and Microsoft is going to drop ADO in favor of ADO.NET. Beyond that, DCOM actually deconstructs ADO into a proprietary string and then reconstructs it on the other side. With all those hoops to jump through, why not just use XML?
The Windows' DNA model
Oak Leaf experimented with the Microsoft XML parser to translate XML but found it to be too slow. Kevin finally wrote his own parser with VFP. Speed comparisons showed that the Microsoft's parser took more than ten seconds to process several thousand records compared to milliseconds with the parser written by Kevin. "I put a lot of time into optimizing the parser," he said.
According to Kevin, "The Executant object is extremely lightweight and fast." The object is instantiated by the application object. Only one Executant object is needed in an application, but the same object can be instantiated as many times as needed. The application knows where to find the Executant through the use of an abstract-factory. The user simply enters the UNC path to where the application server is, and the framework handles the rest, which means the data and application server can exist anywhere. Although the object is released after being used, a reference to it is maintained in the COM+ environment, so that each subsequent call to the object is actually a call to the stub in COM. When the application shuts down, so does the reference in COM.
True to its legacy of providing flexibility, the framework does not force developers to use the Windows' DNA. They can still use the logical three-tier design, but using the Windows' DNA makes the application more scaleable and, in some situations, faster if network bandwidth is an issue because only the data that is needed is passed over the wire.
More client/server support, please!
Codebook broke new ground with its ability to dynamically switch back and forth local and remote data. This functionality was achieved through the use of a naming convention for remote and local views-lv_myview and rv_myview. The first letter was stripped out to create simply v_myview. The application didn't care where the data was coming from, allowing an application to be easily scaled from file server to client/server. The model broke down somewhat if the user needed to use SQL pass though and remote transaction handling. Although it could still be done, there was no native support in the framework. Also much discussion has taken place recently over the benefits of using remote views vs. SQL pass through. There is no clear answer on which approach is best. It all depends on the type of application you are building. In most situations, you'll want to mix and match.
Mere Mortals addresses these issues by incorporating two new objects-the connection manager and the SQL pass through object. Remote views have the ability share ODBC connections. The connection manager makes sure all the views play nicely together on the same connection. If using the SQL pass through, the developer has to manually configure a connection. The SQL Pass through object looks to the connection manager for an available connection. If one is available it increments the share count, otherwise a new connection is created. One of the benefits of this approach is the ability wrap things in transactions on the remote server.
VFP data can be made into client/server by simply accessing the data through ODBC and using remote views. The downside is that stored procedures can't be called through the ODBC driver. The question that first comes to mind is why on God's green earth would somebody want to do that? The answer is simple-network bandwidth. I once wrote an application that crawled on a CITRIX box because too much data was being shoved around over a limited pipe. I solved the problem by accessing my own data through ODBC. Eventually we went to SQL Server, but that solution really saved my butt! Mere Mortals has the ability to do the same. There are two kinds of connection managers-local and remote. The local connection manager accesses VFP data through ODBC using a named connection. There is an option to turn off pre-fetching primary keys, so that calls to the newid stored procedure are not made in the front end. For most situations this type of configuration is unnecessary, but there are times when having this ability can really pay off.
Of course, with each of these configurations, the developer can mix and match. Some objects can access the data remotely, others locally. Which architecture to use depends on what you are trying to achieve. What's important here is the flexibility to do whatever best suits the situation.
But, wait! There's more!
When using business objects on the desktop model, there are times when something happens in a business object that you would like other business objects to respond to. Using the subject-observer design pattern, a "snap-in" tool can be created for business objects that make one business object a subject, or publisher, and another an observer, or subscriber. This is especially useful on a form that needs to "update itself" if something changes on another form.
The types of events that subject and observers can respond to are: Move, Save, Cancel, Delete, New, Requery
Mere Mortals has multilingual support. I suppose it was only a question of time before it happened, but thanks to Vicki Miles of VLM International for "pushing" so hard, it is now implemented. Forms, menus, toolbars and application messages can all take advantage of the multilingual features. And the best part is that you can roll out an application in any language and have the users do the translation by simply pushing a button! Of course, the ability to dynamically switch back and forth between languages is built in.
Support
Mere Mortals offers 30 Days of Free direct e-mail support that doesn't start until you ask your first question. After that, unlimited free support is offered on the Universal Thread.
Documentation
The documentation is what made Mere Mortals famous in the first place. It is now more than 400 pages long and very readable. More importantly, it is well organized, giving developers quick access to information when they need it. Strict attention goes into the documentation, and often releases have been delayed until the documentation was up to snuff.
Pricing
Mere Mortals retails at $339.00 (US) per developer and $299.00 (US) for an upgrade.
Contact Info
Oak Leaf Enterprises 952 Rockledge Drive Charlottesville, VA 22903
http://www.oakleafsd.com
