Let's take a quick look at what the Wizard actually generated. The Visual FoxPro project looks like this:

The Wizard pulls all of the Web Connection framework files into the project. Most importantly though it also created two new source files customized to our new application.

• WebDemoMain.prg
  This is the mainline program that contains the Web Connection server class. This class is named WebDemoServer and the mainline code instantiates this class and gets it ready to run.

• WebProcess.prg
  This is your process class where we'll be adding code to handle each incoming Web request. It contains a class WebProcess and a small stub that instantiates this class on every hit.
  

As you may have noticed by now the servers follow a simple naming convention. Server related classes all start out with the project name and get additional text appended: WebDemoServer, WebDemoConfig, WebDemoMain for the mainline PRG file. The Wizard also generates a build file called Bld_WebDemo.prg that recompiles the project and re-registers the COM object with DCOM as needed.

WebProcess.prg generates the base class again with the same name as the PRG file. The class also contains a dummy method called TestPage, which we are going to use in a second to test the server's operation.

To start the server go back into Visual FoxPro were we left off and:

DO WebDemoMain.prg 

Note that you could also run the compiled WebDemo.EXE file, but here I'm choosing to run the source files directly as we're going to be editing and adding code in a second. Once you run the code you should see the server pop up.

The server window is a display that shows requests running through it. The large area of the format will show requests as they come through with the time that each request took in seconds. Here I ran a maintainence test request to show what the server looks like while it's in process.

The server form also gives you access to the Status configuration form by clicking on the Status button:

The settings in this window should look familar - the settings match the settings I made in the first step when running the New Project Wizard. The most important values are the Startup directory which should be the current directory, the temp directory and the template setting, which are used for the file based messaging that we are currently using to run our server.

Whenever the server is run as a standalone EXE or from within the VFP environment the server uses file based messaging. We can also run the server as a COM object in which case the Web server will instantiate the server itself.

The Web Configuration

Ok, so now our Web Connection server is ready to receive requests and waiting for our first incoming request.

The Wizard also generated a new virtual directory on the Web server with script rights set as well as a scriptmap for the wp extension and points it at the wc.dll.

All of these settings allow you now to access a URL on your Web server as follows:

http://localhost/WebDemo/default.htm

The resulting page from this request is just a test page that the Wizard sets up for you that allows you test the server's operation. It looks like this:

Click on the HelloWorld link which takes you to the following URL:

http://localhost/WebDemo/wc.dll?WebProcess~TestPage

You should get a response page that basically tells you that you got there.

You can actually access that URL a number of different ways because we chose to create a script map in the Wizard setup. The script map we added is for the .wp extension, which now allows us to access requests as follows:

http://localhost/TestPage.wp

The script map allows you to access .wp anywhere in the Web space without having to have an explicit file that matches the URL. There's no file called helloworld.wp in the server's root directory, but the server passes the request on to the Web Connection DLL, which in turn passes it forward to your Web Connection server to process. Here the .wp extension triggers the request to get routed to that same request class as the previous URL that was passed and we end up actually performing the exact same code in the process class.

Why is this useful? It frees you from hardcoding paths to a fixed DLL file, and it allows you to have short URLs that don't contain any routing information on the querystring. Also as we'll see later, the script maps can be used to actually execute HTML scripts containing Visual FoxPro code.