XML in, with, and for VFP

Session Overview

As a VFP Developer, you will find plenty of use for XML in the near future. This session will show you why, and how, you'll use it. Here are some general reasons to keep in mind:

· XML provides a platform- and language- neutral syntax for interchanging information between applications and business partners, so it is ideal for VFP applications that function as mid-tier components, in web as well as non-web-enabled architectures.

· It is ideal for multilingual applications, because XML was designed from the ground up to handle Unicode.

· It provides raw content for unlimited forms of display, so it is an ideal tool to complement the shortcomings of the VFP FRX and reporting systems.

· It is well-equipped to express relational data as well as describe objects, so it is ideal for use in an environment, like VFP, that use both normalized databases and object hierarchies.

As you reflect on the material in this session, you will see many illustrations of these general points although we may not discuss them directly. In this session we'll cover:

· why using XML extends VFP in directions that are critical to VFP;

· practical applications of XML in VFP;

· what's been added in VFP 7.0 to facilitate using XML;

· recommendations for tools and techniques to get you up to speed with XML and its associated technologies.

Introduction (why we are here)

This is going to be a long introduction, more like an essay in itself. I’m going to tell you at least one story and give you some background information.

Don’t worry – I promise that the rest of this paper will also have lots of code samples! If you’re already convinced that XML has a place in your future and just want to get started on “how”, you can skip this section. If you’re interested in the “why”, here we go…

A few weeks ago, I mentioned to John Alden that I was doing a lot of XML-centric work these days.

NB: Some of you may remember John Alden from US Fox conferences or from conversations on FoxForum. He is the author of Raven, a fascinating and unusual Visual FoxPro application, of a type generally referred to as an expert system. Raven “learns” and stores complex decision trees created by experts in various fields and then generate recommendations, diagnoses, or other comprehensive results for less-expert users. (If you want to know more, reach John at mailto:alden@tychosoft.com.)

John responded to my e-mail as follows:

He couldn’t have been more wrong.And, because I’m the person I am, I proceeded to tell him so:

At this point in writing my message to John, I realized that I had an important task in undertaking this topic at the German DevCon this year.

I certainly don’t think you should magically believe that “XML is where it’s at”, no matter where Microsoft or anybody else says you should want to go today. And it’s also true that there are some things you have to experience yourself before they can be meaningful. There is no reason to expect you to derive meaning, or internalize implications, by simply hearing about my experiences.

Still, this session is designed to give you a push in the right direction. I want to let you know why I think XML is so important to your work and how I think you can start using it, now and in the near future, to expand the horizons of VFP applications. I will tell you something about my experiences and extrapolate some general meaning from them, if possible.

No app is an island

Part of the battle has already been won. All of you have written “collaborative software” already. Perhaps you haven’t used DLLs and ActiveX controls explicitly. Maybe you haven’t once exported data to a waiting Excel application or used ODBC to attach to SQL Server or Oracle. You’ve still written collaborative VFP applications.

These days, you are still making use of external components in your VFP applications every time you use GETFILE(). Your VFP app is still dependent on the outside world for help every time you send a REPORT FORM TO PRINT out through the Windows printing subsystem. If your report contains a letterhead image embedded in the FRX, VFP calls the image’s host application when rendering the graphical portions of the page.

All application development environments, including VFP, have weaknesses and limitations. Your users do not accept that as an excuse for limiting functionality, so you write Fox applications that collaborate with other software to get the full job done.

As soon as you write collaborative software, the different components have to talk to each other. XML gives us a way to have a maximum number of components talking to each other with a minimum of fuss.

So… don’t we have COM for this purpose already? Don’t we have established ways to allow applications to communicate? Not really. XML extends your ability to communicate to other environments and applications that do not, or cannot, follow COM rules. Even within a COM-world, XML makes it easier to communicate through firewalls, to transcend configuration hassles, and to alleviate character set and codepage issues. Beyond COM, as you’ll see, the two communicating partners do not have to share much at all.

FoxPro DOS, still great for lots of uses, comes to mind! FPD is not a COM client. But it can parse XML, and it can provide data in XML form. So can almost anything else.

It's true that not even XML is going to spare us from (for example) Fox's non-standard representation of NULLs, or (for instance) vagaries in VB's understanding of arrays. But XML and its sister- and daughter- technologies are better than anything else ever has been at reconciling these, and other, issues.

The people who work on the XML and related standards have a lot of hard-won experience. They are putting it all to good use, designing XML to be both exacting and forgiving, both explicit and inclusive of as-yet-unknown architectures. Just as importantly, these standards are catching on in the real world. All that standards and design work must be paying off! People like using this stuff!

By writing VFP applications that expose XML interfaces, you make your work accessible to more types of developers, who can hook together more types of functionality, than ever before.

As I continued in my message to John:

And now some people at this conference, those of you who have been reading my essays for several years, immediately know why I am so interested.

Publishing everywhere

Starting in 1997’s Frankfurt sessions, I’ve been talking to you about something called “the one document process". I’ve been looking for ways to make it work, for much longer than that. Lots of other people were searching for ways to make this come true, too, even though they might have called it something else.

In a one document process, we store information only once across an enterprise, no matter how many business units need it, no matter how many formats they want for views and reports, even data input screens. When it comes to the metadata that describes our application, the data that describes our work as developers we also have one document. This one document, or dataset, starts with requirements, goes through testing, and proceeds to end-user help files. We generate the necessary output materials as customized views and formats of one set of metadata.

I don’t mean there is one storage facility for every piece of data (like an Access MDB). I simply mean that data is only stored once, wherever it is stored, and tied together with other data as needed. You don’t write a set of use cases or scenarios for your requirements document, for example, and then have the testers start from scratch to write use cases or scenarios. There is one set of use cases, even though they may look different when the testers use them from their presentation in the requirements document. They may be prioritized differently, or offer different sets of details, in the requirements document and the test plan. The same use cases, again presented differently, help end users understand how the finished application works.

In VFP, we were limited in this goal, partly because our abilities to interchange data and present data were not complete. VFP did not suffice for all input, storage, and output needs; it needed collaboration. For example, we might have Visio diagrams indicating process flow and functionality that were integrated into our metadata describing the application.

We weren’t able to communicate with other components effectively. ODBC, COM, and ADO helped somewhat on the data interchange side but we never really surmounted the limitations of the Report Writer to “speak” properly, or present, the results of our work.

With XML, the one document process for development work finally becomes a reachable goal, without all kinds of kludges. It gives VFP the tool to write once, publish every-where, every-what, and every-how.

Some of you may be wondering, how do all the different views of the single document stay synchronized? For instance, suppose somebody adds a use case late in the development cycle, to match a new requirement. How do you make sure it shows up in the documentation, other than publishing a text file labeled README.TXT?

The answer lies in establishing a “publish and subscribe” system, in which all known consumers of a piece of data register their interest in that data. Typically, the consumers indicate how often they would like to be notified of any changes to the data, and/or receive brief notification of all changes, in a form that allows them to evaluate whether this change is pertinent to their “view” of the data

Those of you who are interested in design patterns take note: in this system, we have an Observable (the one document data source), and a lot of Observers (the document views). In a typical system, the document object maintains a Changed flag, and also sends out a notifyObservers event to its registered Observers. The notifyObservers event often passes a reference to an object providing details on the typeOfChange.

Any Observer, such as the help file generator system, may choose to re-generate some items on the fly, cache others every time a change is noted, and recreate others only when specified events occur. For example, a list of links on the web in an on-line help file, showing recommended resources, might be sourced “fresh” from the data source every time it is needed, to keep it up to date. Meanwhile, a listing of examples shown in this help file could be cached on the web server, re-generated only when the examples have been changed in some way. The API listing or the table of contents, for this same help file, would only be re-generated when a release version change occurs. The Observable datasource remains unaware of these distinctions, of course.

Where we will use XML (this is not about the Internet)

Rick Strahl is going to show you how all this affects VFP’s ability to function within a distributed application. These days, it’s true, “distributed” often automatically means “working over the Internet”. Some of my examples will have an Internet component or “background”, too.

However, data interchange and data presentation are problems you have to solve whether you work with the Internet or not. My examples and advice are intended to show you how VFP and XML work together within any component enviroment to solve these problems.

What VFP applications do

Think about what all your applications do, and by extension what you do every day for a living. They all do pretty much the same thing, even John Alden’s “off the beaten track” Raven (see figure 1 below).

Figure 1, An oversimplified, but comprehensive, view of VFP activity.